Also mentioned earlier in the thread, I think. Each REPLACE statement will result in a row lock. So a good refactoring strategy might be to combine your separate statements to one once you've finished troubleshooting.
-- rk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Christina Bull Sent: Wednesday, April 25, 2012 6:08 PM To: [email protected] Subject: RE: lockng issues While we're here... I've always done stuff like Sele MySharedTable Replace x with y Replace z with a Replace t with v Rather than doing it all in one Replace command. I started doing this from a troubleshooting point of view ... if one of the fields had a problem with the replace... it was easy to find which one. Will this: a) slow down the system as opposed to one replace command? b) cause record locking issues? I'm a bit green too I guess. Christina Bull DataHouse www.datahouse.com.au -----Original Message----- From: Mike Copeland [mailto:[email protected]] Sent: Thursday, 26 April 2012 7:21 AM To: [email protected] Subject: Re: lockng issues My understanding is that when you, for example, SEEK to locate the one record you want to UPDATE, then REPLACE (without ALL or FOR or WHILE) then it will lock only the record being updated. As UPDATE is an SQL command (as opposed to xBase) I'm not sure if it behaves the same or not. But I would expect that if you execute an UPDATE...WHERE that optimization may kick in and lock the file header instead of the individual record. But to be fair, I started moving away from shared DBF files years ago and have never regretted it. I let the database backend worry about the locking issues now. Mike Copeland > > [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/DF1EEF11E586A64FB54A97F22A8BD0441D52CAC61B@ACKBWDDQH1.artfact.local ** 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.
