Record Lock Problem

The &quot;solution&quot; is to write an error handler to handle this.&nbsp;&nbsp;Since you are using pessimistic locking, a lock will be attempted when the user starts, rather than at the end/commit of an edit.<br><br>I'm sure many folks here have some error&nbsp;&nbsp;handler routines already developed that they could share; its really the best long-term approach.&nbsp;&nbsp;Also explore the <FONT FACE=monospace>set reprocess</font> command. <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>

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

Robert,<br>&nbsp;I think jvalk's question is how to prevent the application from abruptly exiting.<br><br>jvalk,<br>&nbsp;set a breakpoint just before the attempt to access the locked record. Step through and see where and why it terminates.<br><br>Jon

You're right, Jon:&nbsp;&nbsp;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.<br><br>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.&nbsp;&nbsp;<br><br>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. <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>

Couple issues besides the error handling <br>1.&nbsp;&nbsp;SET MULTILOCKS ON<br>2.&nbsp;&nbsp;OPTIMISTIC TABLE BUEFFERING is generally the preferred method of buffering.&nbsp;&nbsp;Don't know if you checked it out<br> <p>John Durbin<br><a href=mailto: > </a><br><a href= > </a><br>ICQ VFP ActiveList #73897253