>>>Hello all,
>>>
>>>I have a form where two tables will have to be locked. it's a multi-users app.
>>>
>>>I am afraid that if two users get into that form, one could have a lock on table #1 and for whatever reason, the other user could have the lock on the second table.
>>>
>>>How can I make sure that when a given user gets one table locked he will also get the lock on the second table?
>>>
>>>I'm thinking about creating a table where one field would serve to tell me when a locked was made.
>>>
>>>so if field in controlling table tells me that nothing is locked I replace value with .T. so now I know I can lock the second table.
>>>
>>>And other user can't lock until user #1 is finished doing is things.
>>
>>You might want to look into data buffering. Old but extensive article by the late John Koziol at https://www.levelextreme.com/Home/ShowHeader?Activator=23&ID=39374
>>
>>You could also look at VFP transactions if you have to update multiple tables.
>
>But be aware, it hat it own quirks. A write to both tables might fail on one and work on the other. A (not very secure) way is to make sure to always write to both tables, so that the other instance will got a chance to see a change. Usually we write a time stamp on every write. (Optimistic table buffering, row is to automatic for me and pessimistic is just locking). We work on a TS, so the time is synched. Else this might be a problem to consider too. No fail that last 20 odd years, but it's not secure in informatics sense.

Works perfect for me. I have all writing to underlying tables written in a same milisecond by putting all datasession open tables into an array and then commiting changes in a loop wrapped by transaction band.
If changes are dropped then all dirty buffers are reverted by simple loop of tablerevert() on all tables involved
if there is conflict then there is handling of conflict. If some tables are already written before conflict is detected then there is safety of outher transaction band to revert tables to original state keeping referential integrity intact.

Wrote this functionality into my business object underlying classes some 15 years ago and it has been serving me wonderfully ever since. Bonus effect is keeping table corruption nonexistent way after smb2 was gone.
Fact that all 'dirty' tables are always written in some short miliseconds in loop is what I believe is responsible for this little bonus. Never had ANY corruption except for couple of index tables. Never on a tables themselves.

Was thinking to publish this as a generic functionality (shared/buffered access on a native tables) but it seem
that this paradigm has been long gone and very few people would use such thing..

Rgds++
Sergio