>>>>>>>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.
>
>Thats a big mess.
>
>I'm not realy shure right now if this would happen on two comps but with one comp (one account) I'm now at the following
>table open in VFP instance 1 and instance 2, field changed in instance 1
>
>?Field will produce old value
>SELECT Field from table will produce right value. (Subsequent ?field is still old value)
>UPDATE .. field WHERE field=oldval(... reads old value
>if I BROWSE the table , after SET REFRESH (every value, 0,-1 too) the data is refreshed
>FLOCK() / UNLOCK reads the right value
>USE table IN SELECT('table') reads the right value
>
>I could live with the ? problem but the difference between SELECT and UPDATE is strange.
>
>I have tested around.
>
>The problem to the UPDATE occurs only if
>
>the buffered cursor is altered and the target too
>TABLEUPDATE() is run
>the buffered cursor remains and the source is changed (to it's old state)
>-a following TABLEREVERT will not change anything
>-REFRESH(1) will not change anything
>-.CURSORREFRESH will put all back into normal
>
>
>I need a beer. (-_-)

too bad you are not in this area - I am pretty certain that I'd have explained our vfp solution using incremental integers as TS (TimeStamp, not Termnial Server in this context...) plus needed conflict fallback screens while we are both at a state allowing both of us to drive (the size of the beer was not mentioned, and in the states they serve some pretty large jugs). Should be able to take care of a special flag, but probably with some added code for a second "TS" counter easier to follow and debug if some weird scenario sufaces