Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Record Lock Problem

Status
Not open for further replies.

jvalk

Programmer
Jun 28, 2000
4
0
0
NL
I am using pessimistic table buffering and when I want to access a locked record I get error 109. After this the application closes immediately. Has anyone a solution for this 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
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top