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 !
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.