ACC2: TransferDatabase Fails in Code, Not in Immediate Window (117612)
The information in this article applies to:
This article was previously published under Q117612 SYMPTOMS
Advanced: Requires expert coding, interoperability, and multiuser skills.
When you use the TransferDatabase action within a transaction in an Access
Basic function, you receive the error message:
Couldn't update, locked by another user on this system.
-or-
Couldn't update, currently locked by another session on this machine.
However, if you set a breakpoint in the function and single-step through
it, you do not receive the error message.
CAUSE
This error occurs only when you run a TransferDatabase action nested in a
transaction on a table that is already attached to Microsoft Access.
The error occurs because a transaction updates the MySysObjects table,
placing a write lock on the table. The write lock is not released while the
transaction is still active. The DoCmd TransferDatabase statement causes
Microsoft Access to start a new session and try to create a new table.
However, the Microsoft Jet database engine needs to update the MySysObjects
table because it is adding a record, but the MySysObjects table is still
locked.
RESOLUTION
Do not use nested TransferDatabase actions in transactions against attached
tables. Instead, use the following techniques:
- Move the TransferDatabase action above or below the transaction.
- Move the data from the attached table into a local table and perform
the TransferDatabase action on it instead.
STATUS
Microsoft has confirmed this to be a problem in Microsoft Access version
2.0. This problem no longer occurs in Microsoft Access version 7.0.
REFERENCES
For more information about the TransferDatabase action, search for
"TransferDatabase," and then "TransferDatabase Action" using the Microsoft
Access Help menu.
Modification Type: | Major | Last Reviewed: | 11/6/2000 |
---|
Keywords: | kbbug kberrmsg kbusage KB117612 |
---|
|