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 -------- Original Message -------- Subject: Re: lockng issues From: Sytze de Boer <[email protected]> To: [email protected] Date: 4/25/2012 3:55 PM Mike, for a greenie like me, please tell me how to avoid locking entire table, if/when you replace. Is that where Update is better? On Thu, Apr 26, 2012 at 8:49 AM, Mike Copeland<[email protected]> wrote: > Opinion: It is rarely a good idea to lock the entire table. Not that it > isn't a good idea for some purposes, but in most cases, don't lock the > entire file. > > Mike Copeland > > _______________________________________________ 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.
