>>>>I have 3 different forms all using private data sessions. 1 parent and 2 child forms.
>>>>
>>>>The client has requested that when a user is changing a child table that the parent record be locked and no other users be allowed to edit/delete the parent or child table records.
>>>>
>>>>I just locked the parent record, set the child forms as model and keep other users out of the child tables by checking if the parent record is alread locked. Well the problem comes up in that the client wants to access the child form without 1st passing thru the parent form. Now there are two ways to get to the child form and I need to check if the parent record is locked. The client will add more forms and child tables, so the problem will only get worse.
>>>>
>>>>I can't use a formset, it will be way too big and slow to load.
>>>>
>>>>Any ideas or schemes would be greatly appreciated.
>>>>
>>>>John Brooks
>>>
>>>Seems to me, you still have to have some intermediate step to determine which child records the user wants to edit. Maybe in the Form load method you could check to see if the parent record is locked [if locked()] then cancel the form load if it is. If not lock the parent record and continue.
>>
>>
>>No, I have the intermediate step covered of being on the correct chidl record. My problem is that when they click the edit button it needs to go out and lock the parent record, which maybe locked on another form in a private data session.
>>
>>I need to be able check if the parent record is already locked by the same user and if so allow the user to edit the child record or if locked by another user, then not allow the user to edit the child record.
>>
>>The bad thing in this process is that the child record can be accessed without going thru the parent form/table. So sometimes the parent record can be locked in the child form.
>>
>>I leaning toward putting the whole thing in a formset, except for the speed issue.
>>
>>John Brooks
>
>
>I recently worked on a SQL Server system that required a master record to be locked when the user decided to edit it. SQL Server doesn't really allow locking of records. Although there were some 20 child tables involved, I only needed to lock one record, the parent, and whoever has this lock, has all the children at their disposal to.
>
>I wrote a small function in sql server that could be transferred to vfp fairly easily. I kept a small table that stored a few fields, the parent key, the user id.
>
>When a user wanted to edit a record I checked this table to see if the record was already locked (the parent key), if it was I further checked to see if that user was still logged into the system (they may have put the record into edit then shut off their computer and gone home). If they were still logged in, the first person got a message saying the record was being edited and even gave the name. If the person wasn't logged in, I released their hold on the record and this new person got the lock.
>
>After the data was saved, this implicit lock was released. Also, whenever someone logged into the system, I automatically deleted any locked records that might still have been around for them. You always have to deal with the problem of bad shutdowns.
>
>Now, vfp doesn't keep track of who is logged in so someone could edit a record and then shut off their machine and how would you know?
>
>Here is a potential solution. Create an application timer class. Have a login table with the userid, start time, and refresh time. Have your timer class fire every fifteen minutes or so and update the refresh time for that user in the table. (Like a web cookie!) If the refresh time hasn't been updated then you know the user is not on the system anymore and you can delete their record and any locks.
>
>The essence here is that you manage your own locks and don't rely on VFP to do it.
>
>This can all be encapsulated into a lock object that returns true or false when you ask for a lock and has a release method to release the lock when you are done with it.


I like this approach. Thanks for your help