Yep, I found that out during some testing with two instances of my program running. I could never get the TABLEUPDATE to fail. So I copied the SaveRecord procedure from the framework class, put it in my datahandler application class, and then renamed it. So those instances I need to check for a conflict, I can use the modified SaveRecord routine that now has the sllOK = TABLEUPDATE(0,.F.). I surrounded my SaveRecord call with a loop so if the TABLEUPDATE fails I can cancel the changes in the view using the TABLEREVERT() command and then loop again calling a Requery first. I have the loop set to run 10 times so if for some reason the TABLEUPDATE cannot save, I can prompt the user to either retry another 10 times or cancel. In testing on my local machine with two instances of my program running, this prevents the scenario of two users trying to update the onhand quantity with the same starting value. Thanks for all your help!
James Trogdon >>> [EMAIL PROTECTED] 10/28/08 07:23PM >>> >> sllOK = TABLEUPDATE(0,.T.)<< This is forcing the update no matter what. The second parameter should be .F. and I would expect it to fail. From the Help file: llForce: True - Overwrites any changes made to the table or cursor by another user on a network. The WHERE clause uses only key fields. Rick White Light Computing, Inc. www.whitelightcomputing.com www.swfox.net www.rickschummer.com [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
