Larry,

Thanks for the reply and links to further reading.  I’ll check them out
after I post this.
I embedded replys to your questions below.

I have 200 to 250 total users of the database (actually, right now there is
just one, me.  So far I’m running the database on a standalone machine but
have always planed to split FE and BE over the network).  I anticipate no
more than 10 concurrent users, most likely no more than 1 or 2 who are
changing data, the rest just viewing.  80% of the time new data is added (and
edited) from one location in our meeting room.

(2) I have many recordsets that are used by many different forms so I refer
to them as global. The underlying tables for these are on the local users
machine.  I’m trying to minimize the data transfer across the network.  When
necessary to add, edit or delete a record on the BE, I’m using DoCmd.RunSQL
"sql stuff".

(3) Ten at the most.

(4) I read about it here at this newsgroup access.multiuser.  I also tested
the situation where I placed the BE on the network and opened a record for
editing on my computer.  (I have Access 2002 and the database is 2000
version.  The other users will have 2002 runtime.)  I then logged into a
second computer and attempted to delete the record I was editing from my
computer.  This caused the second computer to go haywire.  It couldn’t shut
it down using any software command.  I had to kill its power source and it
left the LDB file on the network.  
Our IS department has reluctantly given me MS access (and network space) but
they made it clear that they do not and will not provide me or my users any
help. Thus, I very concened about network issues. The database is set to
record locking.  I intend to use pessimistic locking and somehow block the
second user from even attempting to change a record that is being edited,
thus eliminating one cause of the lingering LDB and the scary computer lockup
I saw.

[1] I’m not sure how to do this.

[2] Does I/O stand for "input / ouput to linked tables"?

(5) I’m not familiar with the term “replication” and have no intention of
making a home grown version.  Data input usually occurs during a one hour
session 3 times a day, Monday through Thursday.  Each session we typically
add 10 to 20 new records.  It is not critical (but would be nice) that other
users see the added or changed data real time.

[3] What is database corruption in the Back End?  

[4] How do I know if I have it?  

I don’t quit understand the declaration and setting of databases and
recordsets.  I have a module that is not connected to any form that I refer
to as global module (GM).

[5] Is this the right terminology?  

Example of what I have:

Option Explicit
Option Compare Database

'... *** GM Module ***

Public db As dao.Database '...Used while this program is running.
Public rstMembers As dao.Recordset '...Member information.
Public rstProfile As dao.Recordset '...Scenarios setup
Public rstArea As dao.Recordset '...Area critiqued
Public rstStandards As dao.Recordset '...Description of the standards
Public rstCycle As dao.Recordset '...Information for each cycle

The startup form is frmBackGround and remains open until the users closes
the program.

'... *** frmBackGround Module ***

Option Explicit
Option Compare Database
'...~

Private Sub Form_Open(Cancel As Integer)
   '...Refreshes local tables and sets initial information.
On Error GoTo ErrorHandler

   Set db = CurrentDb()
   OPDLogIn  
   DoCmd.Maximize
       '...This is a hidden form use to exit the program if idle time > 10
min.
   DoCmd.OpenForm "frmDetectIdleTime", , , , , acHidden
       ‘…Copy data from network to local tables
   UpdateLocalTables
       '...Creates global recordsets
   Init_RecordSets
       '...Fills arays with initial values
   Init_GlobalArrays

    “more stuff”

End Sub

Public Sub Init_RecordSets()
   '...Creates local recordsets.
On Error GoTo ErrorHandler
       
   Set rstMembers = db.OpenRecordset("tbl_L_Members", dbOpenSnapshot)
   Set rstStandards = db.OpenRecordset("tbl_L_StandardsTemp", dbOpenSnapshot)
   Set rstMethods = db.OpenRecordset("tbl_L_MethodsTemp", dbOpenSnapshot)
   Set rstCycles = db.OpenRecordset("tbl_L_Cycle", dbOpenSnapshot)
   Set rstProfile = db.OpenRecordset("tbl_L_Profile", dbOpenSnapshot)
   
ErrorHandlerExit:
  Exit Sub

ErrorHandler:
  MsgBox "Error No: " & Err.Number & "; Description: " & _
     Err.Description
  Resume ErrorHandlerExit

End Sub

Private Sub Form_Close()
   OPDLogOut
   Set db = Nothing
   Set rstMembers = Nothing
   Set rstProfile = Nothing
   Set rstStandards = Nothing
   Set rstMethods = Nothing
   Set rstCycles = Nothing
   'DoCmd.Quit ‘…Enable before distribution
End Sub

[6] Is there any speed advantage (or other reason) to declaring a second db
when I need to add or edit data on the BE, declaring and setting recordsets
to this new db?
Example:

Dim newdb as dao.database
Dim newrst as dao.recordset
Set newdb = CurrentDb()
Set newrst = newdb.OpenRecordset("sometable", dbOpenSnapshot)

[7] Is it necessary to set the recordsets to nothing if I’m setting the db
to nothing?

[8] Should I close the recordsets before setting them to nothing?

[9] Should I link / unlink the tables on the BE only when I need to get data
from them or put data into them?  Specifically, would this minimize the issue
with the LDB?

Thanks for the help,
sjw