|Subject:||Re: Multiple Forms, Multiple Users
|Date:||26 Aug 2020 13:42:17 -0400
|From:||"Kevin Zawicki" <firstname.lastname@example.org>
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
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.
Tom Krieg <REMOVEtomkCAPITALS@sdassociates.com.au> 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
>> 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.