The "solution" is to write an error handler to handle this.  Since you are using pessimistic locking, a lock will be attempted when the user starts, rather than at the end/commit of an edit.

I'm sure many folks here have some error  handler routines already developed that they could share; its really the best long-term approach.  Also explore the set reprocess command.

Robert Bradley

FoxDev - Visual FoxPro Development

I have a error handler but I don't know how to handle this error.

Robert,
 I think jvalk's question is how to prevent the application from abruptly exiting.

jvalk,
 set a breakpoint just before the attempt to access the locked record. Step through and see where and why it terminates.

Jon

You're right, Jon:  if the application is simply shutting down without his code directing it to (i.e., his error routine isn't giving up and QUITting), then that is seemingly bizarre.

Generally, the approach in your error handler would be to test for that error number (I assume your ON ERROR routine passes ERROR() as a parameter), then set up a loop for, say, 10 iterations, inserting a pause of a second or so within the loop, and issuing a RETRY each iteration.  

However, one of the problems with pessimistic locking is that if someone starts editing, then gets up and goes to lunch, that hoses the other users - error handling will help you exit gracefully, but won't solve the underlying problem.

Robert Bradley

FoxDev - Visual FoxPro Development

Couple issues besides the error handling
1.  SET MULTILOCKS ON
2.  OPTIMISTIC TABLE BUEFFERING is generally the preferred method of buffering.  Don't know if you checked it out

John Durbin


ICQ VFP ActiveList #73897253