Lutz,

I cannot get a clear visualization from the description (and am in a bit of hurry...)
You have to think of the (bulk) update you want to make and the possible update strategies done from other computers/programs as a whole.
A lot depends on how other applications will handle their updates - writing out only changed fields or whole records and what checks are done to the record before that. There is a lot of reason behind forcing everybody out, bulk updating and allowing normal use to resume.If that can't be done, you often have to create stage tables and do single updates flowing with the update pattern used in the other applications (and adding RLOCK into that pattern is not nearly as disruptive as each lock is short). If you have different update patterns in those applications, get the process rolling to streamline into one pattern. Otherwise leave or be ready for nerve wrecking discussions...
One of the nagging doubts from your description is that other apps might happen to overwrite your in-between changes - is everything working with CA and wgich fields are updated ? Do you have a TS-based logic in place ?

HTH

thomas

>>>>>How to force read of a DBF?
>>>>>
>>>>>I have a dbf in concurent use.
>>>>>
>>>>>This is, a record is changed.
>>>>>I try to TABLEUPDATE, this fails due to a field changed. This is intended.
>>>>>If I set the field wo the right value TABLEUPDATE still fails. A SELECT will bring right result.
>>>>>
>>>>>The only way to force right result right now is to close the dbf and let TABLEUPDATE reopen it.
>>>>>
>>>>>Any idea aside USE IN SELECT(cALIAS) to force the dbf to refresh?
>>>>
>>>>FLOCK() / RLOCK() should do it.
>>>>
>>>>My understanding is, by design, those are the ONLY ways you can be guaranteed to get the currently persisted values.
>>>
>>>Whats more ugly:
>>>xLOCK() or USÉ IN xx -> USE xx
>>>
>>>IOW the locks interact with other process using the table. Will USE be better in that sense? It's a rare case, I can do with reopen it ..
>>
>>At the risk of repeating myself, you *have* to get a lock to be assured to have the current, persisted value. That is by design.
>>
>>Three ways to achieve that:
>>
>>1. USE SomeDBF EXCLUSIVE
>>
>>2. USE SomeDBF SHARED, then FLOCK()
>>
>>3. USE SomeDBF SHARED, GOTO MyRec, then RLOCK()
>>
>>If you can't get an appropriate lock, you can't be assured of the current data.
>
>Hi Al,
>
>thank you for your reply. I see what you mean. But it's not that easy.
>
>I have a parent table
>I need to import (insert/update/delete) it's child. But only the child of some records of the parent. All other should proceed as normal. (No FLOCK here)
>The parent could be altered without any harm to the import at any time except one field (see below).
>
>I need to tell the stuff dealing with the childs to not alter some child sets. (no sense in RLOCK, the forms dealing with the child records could insert on there own.)
>
>So I need a flag in the parent to mark the stuff as blocked and deal with this flag.
>
>So now I start import
>
>I check my flag if set somebody else is importing (or the like), possibly wait for rest.
>Now I set the flag via tableupdate. (remember, any other change on this record is to be allowed). And now, if the flag is set be a different process in between - I wait for a change by repeating the tableupdate until timeout or success.
>On this place the data gets not updated. (I reset the flag on external process but the tableupdate still fails)
>I need (and update, tested via CAs events) only this flag, anything else in the record is meaningless.
>
>As far as I understand the tableupdate does some hidden locking.
>
>Lutz