Presumably, you're referring to server-side scripting? Scripts do not run concurrently against the same database. If one is still running when another is scheduled to start up, it will be pushed back and wait its turn.
That sort of makes your second question a little fuzzier, but the answer is yes, it's a separate session for each schedule. And no, they don't overlap.
Yes, I am referring to scheduling server-side scripts. Thanks for the quick response.
Actually, need one more clarification. If two schedules run against the same file, but as two different accounts, the schedules still are queued, correct?
(Basically, it seems to us that schedules are running concurrently).
Doesn't matter. Schedules executed against the same file still run sequentially.
What makes you think they're running concurrently? You mentioned globals. Are you seeing behavior that makes you think they're stepping on each other?
Yes, exactly. We're chasing down unexpected values. You have confirmed what I thought to be true. Also, I would add that to my knowledge, each schedule run acts as if the server opened the file, and so runs the File>Open script. That script sets global values. If that is the case, we should have "1000" in a certain global field. However, we are seeing a different value (in the field that is set to the global value). And the value isn't the same each time the script runs on server. So, we thought, perhaps another server script is running concurrently and over-writing this global value. Even if schedules run by two different accounts ran concurrently, I'd expect them to maintain distinct sets of globals (as do user sessions).
Just not seeing how this global is changing from 1000, and questioning all assumptions.
Those kinds of problems are frustrating.
I found one once where I was setting a Variable, then in the next step one of my calcs used a Let statement that set the same variable to another value. Took me 2 days to find it.
Yes, the OnFirstWindowOpen trigger script will run when launched from Server.
My question in something like this would usually start with compatibility. Are you certain all the script steps involved are Server-compatible? If not, you can wind up with odd behavior.
My second place to look when something like this is happening is access privs. What account is being used to log in from the server, and does it have the right privileges?
Third, check to make sure you don't have any subscripts running that change the value of the global field after the face (like in Joshua's example). That's a hair-tearing experience, for sure.
Beyond that, I'd start looking for issues specific to the solution. How are you determining that the global in question isn't being set properly?
That should read, "...after the FACT..."
Fumble fingers. :)
Global fields belong to the Filemaker client, not the server, and can be different from client to client, depending on their input.
When a a server-side script sets a global field, the value is retained in the served file. Future client sessions will start with the global having that value, however for existing clients (i.e. those who opened the file before the script was run) the global's value will not be affected.
Could this explain what you are seeing?
All great ideas, and I certainly appreciate the empathy!
The schedule is run with a full-priv account "server." The global is set in the open script, and I've read thru the script and its subscripts and cannot find (yet) where its value is changed. Going crazy and that's why I started to second-guess the expectations I had of a server scripts and globals, etc.
I'll find it. I like the Let $var idea in a calc, so yes, the reset of this global is probably hiding somewhere. Meanwhile, I've explicitly set the global just prior to when I need it and we'll see tonight. Many thanks to all.
You could avoid the who global field value issue (unless it's used for a relationship) by setting a $variable in the script and referencing that value instead of the value of a global field.
It's a lot easier to control a local variable while a script runs, regardless of what may be happening with global field contents.
The global is used for a relationship.
Well, I "reset" the global just before I need it, and my records now have the proper value. However, I've yet to find where the value is changed from File>Open to the step it's needed. But, I don't have the time now to keep looking.
Remember that globals are session-specific (by both user and each login to that file), so they need to be set after the file is open anew each time by each user instead of relying on them to persist from any previous session.
The safest thing to do is to assume that any global value (other than a global calc) will be either wrong or empty at the point where each user logs into the file, and set it explicitly before relying on it.
It may not really be that bad, but you won't go wrong if you assume a worse-case scenario like that.
The only non-calc globals that persist in Served files are those which were left set the last time the file was opened UNhosted, and you shouldn't assume those values are what you want unless you consciously planned for that before the system was put on the server.