Just copy the records you need.  Place pseudo locks on those records so
other's cannot edit the same ones.
You can duplicate master/child in the copies.
"Look up" data can be "live" and not have to be copied.

On 8/26/2020 12:13 AM, Peter wrote:
> Yeah I have done that a couple times, there are two main problems that I
> couldn't resolve
> 1. I can no longer do a relational link (master/child tbls) in the
> form's datamodel
> 2. if someone changes the "real" table then all the private tbls need to
> be updated with those changes
> 
> But okay I got the answer the answer I was looking for, client/server
> model. I'l have to do some research on this. Thanks Tom.
> 
> Peter
> 
> On 8/25/2020 8:14 PM, Tom Krieg wrote:
>> Emulate a client/server model using TCursors and libraries. Extract
>> the data you want to private tables and use those in your forms.
>> Whenever you need to update a "real" table use a tcursor.
>>
>> It's a lot of work to begin with but once it's set up it's RAD.
>>
>> But if you're going to do that, you may as well go all the way.
>>
>> On 26/08/2020 10:30 am, Peter wrote:
>>> So far I have only developed apps that let users use one form
>>> (module) at a time. I usually have a central form that lists all the
>>> modules for the things they can do. They select one, do their thing
>>> and then close it in order to go back to the central form and choose
>>> another module.
>>>
>>> When I start dreaming of setting things up so that a user can have
>>> more than 1 form open at a time the logistics of tbl/record locking
>>> is mind boggling.
>>>
>>> For instance, they could have one form open which has one or more
>>> locks on some tables in the datamodel of the form. If they opened
>>> another form that had even one of the tables in the datamodel of the
>>> first form then there would conflicts with record locking.
>>>
>>> How does one get around this? Thank you.
>>>
>>> Peter
>>