Discussion in 'Microsoft Access' started by Guest, Mar 27, 2005.
If you want a helpful answer, it is always best to type your question into
the message body, instead of just including it in the subject. You should try
to provide sufficient detail, so that others will stand a better chance of
providing the correct answer the first time. For example, what are you doing
when you receive this error? What version of Access are you using? What
service packs do you have applied to Access and the JET database engine?
Which operating system are you using? A lot of very knowledgeable folks
simply will not spend time attempting to answer questions with insufficient
detail. I've decided to make an exception, since it's a relatively slow night
tonight. So, lets see......
The Microsoft Jet database engine stopped the process because you and
another user are attempting to change the same data at the same time.
I can only guess that you are getting this error while attempting to edit a
record. But I have no idea if this is a single-user database or a multi-user
database. If it is a multi-user DB, is it split into a front-end (FE) and
back-end (BE)? If it is split, does each user have their own copy of the FE
installed on their local hard drive (so that they are only sharing the BE)?
This error can be caused by having a locking database file (*.ldb) that was
not properly deleted when the last user exited the database. There are
various causes for a .ldb file to be left hanging around, including:
2) the last user out does not have delete privlege on the shared folder
3) improperly exiting Access (ie. crashing out)
With Access closed (and no other user having the file open in a multi-user
environment) the locking database file should be automatically deleted. If it
is not, then use Windows Explorer to delete the file. These files are
typically 1 KB in size. Be careful to delete the .ldb file, and not your
actual .mdb file.
Introduction to .ldb files
The concurrency error can be caused by a genuine concurrency issue, or by a
First, address the possibility of a genuine concurrency issue. Examples:
- code in Form_Open, Form_Load, or Form_Current that dirties the record;
- opening a recordset, and not closing it;
- opening two instances of the database on the same computer;
- opening the same database on two different computers (as distinct from
splitting the database and giving each user their own copy of the front
- having the same data open in two forms at once, particularly if dirty or
if there are BLOB fields (memo, hyperlink, ole object).
It can also help to explicitly save the record before doing anything that
requires it to be saved, such as moving record, applying a filter, setting
OrderBy, changing RecordSource, closing the form, and so on.
If none of those kinds of issues apply, then we are looking at a corruption.
A Decompile is the best bet, though a Name AutoCorrect failure could also
Try this sequence:
1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why:
2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact
3. Close Access. Make a backup copy of the file. Decompile the database by
entering something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
4. Open Access, and compact again.
5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.
At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, and reference ambiguities are
If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
Recovering from Corruption
Allen Browne - Microsoft MVP. Perth, Western Australia.
Reply to group, rather than allenbrowne at mvps dot org.
"code 3197" <code > asked the subject question
Separate names with a comma.