Hi!

First of all: I do not know the source of the problem. I did get similar problems few times, but they went away and I did not catched anything significant that can help to reproduce the problem and find the source of problem.

I will attempt to give a few starting points where to look and what to do to at least get closer to solution.


It is possible that error is exactly the bug mentioned by Randy Waldman in Message#660278 (It is in this thread). It really worth a look - because table is buffered, no locking occurs at all, or locking occurs only client-side when editing records in the table. Locking occurs at server-side only when updating data. Because client-side locking, the problem in mentioned article is ver possible.

It is possible that database is attempted to be locked, not the table, that is why you get incorrect table name.

It is possible this error is in deep internals of VFP when working with grids. Error handler as a result will not be able to determine correctly the source table of error. I recommend you to write a simple loop proram that loops through all data sessions and all aliases and attempt to use RLOCK() for current record and see what happens. There is a chance you will find offending table this way, though chance is very little.

It is possible there is a problem with indexes for table.

Try to catch that error in error handler by some way and ignore it or work around it by some way when it happens for that grid.

Hope this helps.


>Hi everybody,
>
>We're still having a problem with couple of my applications, when the users get "Record is in use by another user" error message. This error has only Ok and Help buttons with not much info in it:
>

>Record is in use by another user (Error 109)
>You have attempted to write to a record that is locked by another user.

>
>The typical scenario of the problem is:
>
>15+ users are in the system doing different kind of jobs... Parcel Processors work each on his/her own workfile and nobody else is using the same workfile. They have a grid for editting. Sometimes the error message pops up immediatelly after they click on the textbox in the grid, sometimes after they press delete or backspace button. File is table buffered, all other tables are used for lookup purposes and used in shared noupdate mode (or they are read-only cursors). My colleague added ALIAS() and RECNO() to the error handler call, however it reports Login table, which is in different datasession and unrelavant for this application. The problem is sporadic, though could be reproduced...
>
>Do you either experience this kind of problem and what would be your suggestions?
>
>Thanks a lot in advance.