>>>>>>>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.
>>
>>In order to do any kind of update to VFP data tables/files, locking is required. What I've been talking about so far is explicit locking, which you can use to have manual control. Other commands will attempt implicit locking as required, saving you from having to manually lock things in advance. However, if there's contention any locking action, explicit or implicit, may fail so for reliability you need to wrap in TRY...CATCH or otherwise handle the errors that may arise.
>>
>>I haven't used CAs much and I'm not sure exactly what you're trying to do. It might be worth reviewing VFP help e.g. Programming for Shared Access...Managing Conflicts when Updating Data and the settings you're using for things like SET REPROCESS, SET MULTILOCKS etc.
>
>Hi AL,
>
>CA is like VIEW with some wrapping and without DBC container.
>I think the TABLEUPDATE mechanism does the implicit locking. My problem is that a TABLEUPDATE (what is implicit UPDATE) does not see the change of a field on UPDATEs target. TABLEUPDATE on wheretype 3 works as
>

UPDATE table SET Field=buffer.field WHERE Field=OLDVAL("field","buffer") AND Key=OLDVAL("Key","buffer")

>I play with table.field
>A
>

SELECT field FROM table WHERE key=OLDVAL("Key","buffer")

>returns the right value of field but the UPDATE fails.
>If I suspend programm and BROWSE table the UPDATE is successful
>
>I will give SET REPO a try.

did you try lForce in BeforeUpdate ?