Unlike many other types of shared files, an Access file is not completely
loaded into memory when opened, nor are all writes to the file only
committed to disk when the file is closed or when the user explicitly
asks for it.  While using the front end file Access is constanly
retreiving pieces of the file from disk and writing changes back to disk.
With multiple users in the same file this can often lead to conflicts and
ultimately to corruption.

While splitting has long been recommended, Access 97 actually tolerated
multiple people using a shared file much better than the newer versions
and many people "got away with" doing it that way.

In addition, there are often times when the developer might
manipulate objects during runtime (like changing the SQL of a QueryDef) to
perform a particular task. This creates problems if more than one
person is using the same file.  I do this all the time to manipulate
PassThrough queries against ODBC connections to server databases.

There are many reasons to do this:

1) Probably the most important is that since the introduction of Access
2000, you cannot make any modifications to the application (forms, reports,
or code) while anyone else has the file open.  So to modify your app, you
either have to kick everyone else out or work on an off-line copy.

2) Working on an off-line copy presents a problem, though.  Since in an
un-split database, both the data and the application reside in the same
physical file, any data added or modified in the production database won't
be in your development copy when you put it back into production.  So again,
either everyone has to stay out while you modify the application or you have
to find some way to copy new data into your development copy before putting
it into production.  Neither option is very viable.

3) Having a split database allows you to work on your application with dummy
data.  I usually have a test back-end that I link the front-end to while
doing development.  Then I can add and modify records without jeopardizing
real production data.  When I have finished testing, I link the development
copy back to the production data, then deploy it into production.

4) Applications where the FE is stored on the individual workstation while
the BE resides on a server is far more efficient and is the recommended
topology for multi-user apps.  This will also make your application far more
stable.

Now, having the FE on each workstation also has it's problems.  Chief of
which is how to keep all those front-ends synchronized -- that is, how do
you push it out to everyone's machines to make certain all the users have
the same copy.  I have developed a couple of solutions.  They can be found
on my website (http://www.rogersaccesslibrary.com) as small sample databases
called: "KeepingDatabasesInSync.mdb" and "KeepingDatabasesInSync2.mdb".
Also, Tony Toews has developed his "Auto FE Updater"
(http://www.granite.ab.ca/access/downloadsindex.htm), which does much the
same thing.

Hope that helps.