global data

[shogunjp]

I know and understand the reasons that global fields will revert themselves in a shared environment, my solution to that problem was creating a related file with regular fields and having one record in that database. well I realised that that really didn't work either, because if two people had the database open, they would both be on that one record, and unless you exited in the right order you wouldn't update that record... my solution to that was to create a second record and have a script that on the opening of that database made sure that it was not on the first record...

which leads me to the question...

is there a good way to have a variable which anyone can update and will ALWAYS store itself?

and my second question...

I also realised that there was a slim chance that if one of the records that was active because the database has to have one active record, even if it is hidden were to get written to by one of the clients, it might not get written to because one of the other clients may have it open....

is there a solution for this?

I don't know if any of this makes sense.. but some help would be greatly appreciated!

Thanks

Nathaniel

[Vaughan]

"is there a good way to have a variable which anyone can update and will ALWAYS store itself?"

This is a bit like the database synchronising issue that regularly pops up...

The challenge is the multi-user environment... At some point there will be two or more values for the one variable, one at each guest user's machine. What set of rules should determine the single stored value for the variable at the end of the day? Currently with FMP it's the last one to log-out. This as logical solution as any other IMHO.

As you have discovered, any other algorithm is difficult to implement, too.

[shogunjp]

hmm.. ok.. well i do understand the logic behind filemaker and how it handles multi-users....

Is there a good way to try and minimize the chances of data being written, and then overwritten? like say having people idle out of files quickly.. or coming up with an algorithm so that a related (hidden) file doesn't always open up to the same record?

[DykstrL]

You could use a client "Open" file that would store the user's information and "upload" it to the hosted file globals to be used there. Then on exit, have the client file reset its information based on changes made made during the session on the hosted file.

[jwmickelson]

My FMPro solution regularly has 50-70 users and is serverd via FMPro Server. Anyone who designs a large database system runs into this problem. Creating one record in a single file that everyone uses for storage of variables is the basic answer. The trick is to not allow users to manually access this single record, use scripts to send data to those variables. Thus, they can't lock the record by leaving their cursor in it.

Now, in a multiuser environment, if users are not 'continuously' updating these values, it is not too dificult to use some validation scripting to make sure thay were able to update the record you want:

Status(CurrentError) can be used just following an update, such as a set field, to determine if the change occured. When used in tandem with a loop, you may be able to automate this process, where the user waites till the value is reflected in the system.

The single most difficult problem to fix is the lag between server and remote clients, where , for some reason, even after a change has been made in field, other users still see the old value for a short period.

This has yet to be adequately dealt with, and I have not seen any good answer to this except, to manually insert a delay to certain critical functions and use a second variable to determine whether another user is also performing the same script.

IMHO, this single problem gives powerful amunition to people who detract from FileMaker Pro as a robust relational database.

I sincerely hope this changes,

Jonathan