>Sounds like your problem is more elaborate than mine. I only need to lock one record. The way my app is set up, if you can't edit the header, you can't edit the detail, so there's no reason to be locking all the tables.
>
>I'm going to give the seperate table for locks idea a try. Good luck with your program.
>
>Thanks,
>
>Michelle

Well, your logic is the same as ours : header locked means no (update) entry to the order (etc.) lines. So I guess your app deals with one such a situation only ? hmm, we have a couple of hundred (near 1,000 in fact).

Good luck to you too.
Thanks.
Peter




>
>
>>Okay, all is clear now.
>>And the funny thing is, that both you and me are having the same problem. You, because you kind of hate the long way around for somehing that should be dealt with for you (by VFP, or by something with regards to the remote DBMS (it's really the same problem there), and me because I am just using the basic RLock stuff, but having to move to the remote DBMS.
>>So what I'd need is some advance locking, instead of the user hearing afterwards that his/her upgate got rejected. You solved the advance locking by means of the simple - but long way around procedure.
>>And like you, I don't want to do it like that.
>>
>>Actually, I hope that someone else jumps in with the good idea.
>>To give it a headstart :
>>
>>As I understand, you have one of the (for the transaction) leading records "locked", and you have to do that for every set of tables for the various transactions ocurring. True or (understandable) or not, is not all that important IMO. But :
>>Why not having one table with a field for [TableName], a field for [PK] and a field for [WhoLocked] (and [When] etc.). In this way, you can have generic code to have your own locking mechanism.
>>
>>Note that in your case, you can additionally RLock the records in that table, just in case someone shut down the whole app illegaly, and the process of (e.g.) adding/deleting records in there, could check for unlocked records and delete them. In the case of the remote DBMS this would suffice, and something else has to be found to remove records which remain illegally.
>>
>>I guess that I myself will go somewhere on this path, unless someone explains to me (at last) how a user can be prevented from starting a transaction that can't be accomplished, without this fuzz.
>>So, anyone ?
>>
>>Cheers,
>>Peter