multi-user global workaround?

[n1k0]

Hey all,

I've been wondering why FMP7 added accounts without also adding 'account specific global variables'. In other words, why don't users have their own scratch space? It seems that all the multi-user woes are intact... using 'lock scripts' and the like.

But by adding non-global scratch fields to an "accounts" table (containing all the active accounts), shouldn't I be able to make a relationship where "get(accountname)=accounts::accountname" and thus access temp records from a particular user? The first problem of course is that in the above relationship, "get(accountname)" needs to be an existing field.. can it be a global calculation?

I'll try this stuff out and post my results, but I'd love to hear from the masters on this..

Regards,

n1k0

[Ender]

Globals really are scratch space for each user, but they are temporary to that session. If you're looking to remember settings from session to session, then this can be set up in an Account table, with regular fields. To reference fields in this table, you could set a field at login gCurrentUser and relate with something like Account::gCurrentUser = Account::AccountName.

[n1k0]

Globals really are scratch space for each user, but they are temporary to that session.

Ho, Ender. Wouldn't that mean that no 2 users ever see the same global? Also, what exactly is a session?

I'm attaching a test db demonstrating an account-based scratch data solution (login as 'test1','test2' or 'test3', no password). I don't have multiple machines to test it in a true multi-user environment, but I think this will guarantee that multiple users can enter data at the same time without conflict. Can the same thing be done with globals?

n1k0

globaltest.fp7.zip

[Ender]

Ho, n1k0.

A session is each time a the database is opened on a computer, for the duration that it is open. In FM5/6, globals default to whatever they are when the file was last opened in exclusive mode, either offline or with no other users on, then going to Define Fields. So if globals are left blank, then they will be blank to start each session.

I don't recall how they behave in FM7, as editing the schema can now be done while other users are in the file. Maybe someone can fill us in here.

[n1k0]

Let's say I have two tables: CLIENTS and LETTERS (one-to-many). In FM6 or 7, will the system choke if two users are writing letters simultaneously using a global field 'Letter Scratch' for entry?

Are there no available guidelines for coding robust multi-user systems?

[RalphL]

If the fields are globals then each user has their own set of globals. The second user does not see the value entered by the first. Globals are local to one computer.

[CobaltSky]

Hello n1k0,

The first and most important guideline for coding a robust multi-user system is *not* to make assumptions about the behaviour of the application in multi-user mode based on its behavior in single-user mode.

The second guideline is to test your code progressively with multiple users connected.

Beyond that, there are, of course, a variety of things to look out for - most or all of which will quickly become evident if you are developing in a multi-user environment.

For example, the first time you test a solution in multi-user mode, it will immediately become clear to you that global fields are specific to the client session in a hosted solution. So, as others have said, what one user writes to a field is not visible to others and several users can simultaneously write to the same global field without conflict.

You will also discover that marking records and any procedures which depend on the marking of records is catastrophic in multi-user mode because each user's marks overwrite and interfere with those made by other users. Scripts which mark records and which work fine in a stand-alone solution will not be dependable in a hosted solution.

You will discover that solution design must be built around considerations about the locking of records, to minimise situations (as far as possible) where users will impede each other by claiming 'communal space' (eg preferences or resources records etc) in the database.

You'll also discover that procedures which pass through multiple records (replace contents, relookups, scripted loops etc) produce variable results in a multi-user solution because not infrequently one or more of the records in the set being processed is locked by another user. Some procedures (a scripted Set Field[ ]) generate an error code when this condition occurs (but that is only useful if you trap for it and set up a handling routine), but others (eg Replace Contents[ ]) do not, and are therefore best avoided in multi-user solutions.

Leading on from this, it will become clear to you that in a hosted solution, most scripted actions should be followed by appropriate error checking and error handling so that conflicts are gracefully resolved.

If you dig around a bit, you'll find references to all of the above considerations in various historical threads on this forum. There are also numerous books on the subject if you want to extend your research in that way. But even with the best guidelines and reference materials, it would nevertheless be unwise to produce a multi-user solution without testing its multi-user functionality progressively as you develop it.

[n1k0]

Thanks so much for the replies! Great info here, I hadn't considered locking errors in script loops.

How would one go about created a global that was shared across users? Obviously a calculation (i.e. field 'tax calc' = "8.25") with global storage would be shared among sessions, but what if I wanted a field that any user could edit? Is there a solution other than a globals table with one record and non-global fields?

p.s. If the Forest Guardian Vessel is ever reproduced, put me on the list! I tried ordering it a few months ago in vain...

[CobaltSky]

How would one go about created a global that was shared across users? Obviously a calculation (i.e. field 'tax calc' = "8.25") with global storage would be shared among sessions, but what if I wanted a field that any user could edit? Is there a solution other than a globals table with one record and non-global fields?

A global field, by definition is particular to each client workstation. However on occasions global data can be derived from non-global sources and therefore will be read the same across the solution. A global calc which references only non-global data fields is one such example, as is a global into which non-global daata is loaded at start-up. However data written to a global field is not visible nor accessible to other users and nor does it persist after the client session concludes.

If you want to have data that is common to all users amd in which changes made by one user can be seen by others, then as you say, a one record table with non-global data fields is the solution.

Meanwhile, thanks for the compliment about Forest Guardian Vessel.