On 27/08/2020 3:42 AM, Kevin Zawicki wrote:
> To expand -
>
> I have many apps like this...
> Some even allow multiple copies of same form and different forms open.
>
> A user can lookup a customer on customer form, see their product, jump to
> the product screen (seeing the customers product listings, jump to product
> details screen, etc. Can open multiple customer forms and see multiple customers
> at once.
>
>
>
> simple example
> Create empty "PRIV" tables that hold keys. I keep these in the app folder.
> They can be whatever structure you need, say, the key fields and a sorter
> or display logical field.
>
> Have a method that copies these "priv" tables to users PRIV.
>
> Populate, then open form.
>
> You can have the temp PRIV table keyed and link back to master "live data"
> in 1:1 or 1:M.
>
> This can also act as sort of a super filter, in the priv you can only load
> key fields with what you want to see and link back.
> The link back CAN be live editing and locks are handled natively.
>
> So the PRIV table is the MASTER. You can even dymanicallynamethe master with
> a number and oopne the form changing he master on the fly, so if you open
> more than one copy of the form, each copy has its own master copy in PRIV.
>
> There are many variations on this, you can allow ediitng / or simply use
> it to show common data, etc.
>
> Most people use this model for reports as well.
>
>

This glosses over an important consideration - the updating of the 
"master" record as you put it. This is trivial if only one user can 
access a dataset at anyone time.

However, you need to consider the scenario where two or more users open 
the same dataset at pretty much the same time, make changes and then update.

Who wins?

How you deal with this is pretty much dictated to by Business Requirements.

But keep that in mind as part of your redesign.

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus