I understand your concern, but actually, global fields were specifically designed to avoid this problem.
Global fields DO behave differently in multi-user situations than when the file is not shared over a network. In multi-user files, each user gets their own "virtual" copy of any global fields. Thus, changes they made to a global field will not be visible to nor will they affect other users. The catch here is that any data stored in global fields revert back to the value originally stored in the global field before it was hosted as a network file each time a user closes the file. Thus any edits made to a global field will not persist when the user is accessing a shared file.
e-e-e-excellent. Oh wait, I had to create a global number field because I had to create a reltionship between it and my catalog database to automatically fill in lines in the portal. So I'm in trouble, aren't I?
Okay, how about this for using a global field in a multi-user environment. Since the value of the global field at the start of a script doesn't matter (in my case) let's say at the end of every script that uses gCurrentRow, I return the value to 0. When a user starts up a script, the script checks the value of the global field. If the global field is not 0 then the script runs a"time wasting" loop that takes one second to complete and then reruns the same script. What do you think? And is there a a command I can use to wait for a second (pause and automatically start a script)?
Oh wait, I had to create a global number field because I had to create a reltionship between it and my catalog database to automatically fill in lines in the portal. So I'm in trouble, aren't I?
Nope. I was talking about global fields and they will behave as I described. I mis-read your post to be asking about global fields. So my mistake canceled out your mistake to produce an answer :smileywink: