Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 316
  • Last Modified:

Error in VB "Couldn't save. currently locked by another user."

I've write a multi-user database system using VB4 under Netware 3.12 network (about 40 users).

In this system, all recordsets are opened in shared mode.

Sometimes, the warning message will be displayed when my users want to save or update data into database. This situation is un-predictable.

The error message is "Couldn't save; currently locked by user 'name' on machine 'name'. (Error 3186)".

According the help in VB4, the explaination is :-
"You tried to save a record on a 2K database page that is currently locked by another user.  Wait for the other user to finish working with the record, and then try the operation again."

However, I sure that nobody is currently locking the table.

After I restart the program, the problem is the same.

Is it a multiuser JET/Access environment problem in VB ?
If yes, how to solve it ? If no, what's problem and how to solve it ?

Thank you very very much !
1 Solution
When a user updates a record, it's important that some other user isn't allowed to update the same record at the same time. Different databases use different methods to ensure this. Some lock only the record being updated. Some also lock the records immediately before and after. Access locks the 2k page on which the record appears. While this may be simple to implement and/or efficient, it isn't very friendly to other users, since their completely unrelated updates can be locked out while the original update's in progress. Though there's nothing you can do about the 2k page locking, there are things you can do to limit its impact on users. On of the arguments to OpenRecordset (called lockedits) specifies whether you'll be using pessimistic or optimistic locking. Briefly, optimistic locking locks the record only as long as it takes to update the record in the database. Pessimistic locking locks the record (and the 2k page around it, remember) between the call to the edit method and the eventual update. The advantages and disadvantages are pretty obvious. Locks are held longer with pessimistic locking, but you're a lot more sure that updates will work, your users are guaranteed to see the most up to date data, and updates won't accidentally be clobbered by someone else's almost simultaneous update (last one wins). Transactions imply pessimistic locking (i.e. locks are held for the duration of the transaction, even if you're using optimistic locking). Pessimistic locking can be really bad if a user begins an edit or transaction then leaves for lunch, because in Access they're holding a lock not only on their record but on any other record that happens to fall on the same 2k page. There's no simple answer for how to deal with all this, but I hope this discussion gives you some understanding of what's occurring in your app. In brief, to minimize locking conflicts, don't use transactions and do use optimistic locking. Just be aware of the tradeoffs that come with these approaches.
raymondc050497Author Commented:
Thank you very much!
In fact, I already know your proposed answer before.

However, I can't use the optimisitic locking and without transaction.
It is so dangerous and make large impact to users.

In my program, I use the pessimistic locking with transaction.
After user presses save button, I lock the record and resolve data and then save into database.

I think that it isn't related to this problem. It is because the problem is sometimes happened even though only one user is using the program after one user exits the program.

In other case, users sometimes can't update record using the True DBGrid (bound mode) in my program.

The above mentioned problems are happened uncertanity and un-predictable.

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now