>>>>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