1 2 Previous Next 18 Replies Latest reply on May 11, 2012 12:43 PM by Mike_Mitchell

    Sessions, globals and FMS

    BarbaraCooney

      I need clarification. Do overlapping schedules run concurrently or will one wait until the other is finished? If they run concurrently, and are run by the same account and each sets the same gField to a different value, do they overwrite each other...or are they seen as separate sessions each with its own set of globals?

        • 1. Re: Sessions, globals and FMS
          Mike_Mitchell

          Hi, Barbara.

           

          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.

           

           

           

          HTH

           

          Mike

          • 2. Re: Sessions, globals and FMS
            BarbaraCooney

            Yes, I am referring to scheduling server-side scripts. Thanks for the quick response.

            • 3. Re: Sessions, globals and FMS
              BarbaraCooney

              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).

              • 4. Re: Sessions, globals and FMS
                Mike_Mitchell

                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?

                 

                Mike

                • 5. Re: Sessions, globals and FMS
                  BarbaraCooney

                  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.

                  • 6. Re: Sessions, globals and FMS
                    jormond

                    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.

                    • 7. Re: Sessions, globals and FMS
                      Mike_Mitchell

                      Barbara -

                       

                      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?

                       

                      Mike

                      • 8. Re: Sessions, globals and FMS
                        Mike_Mitchell

                        That should read, "...after the FACT..."

                         

                        Fumble fingers.   :)

                        • 9. Re: Sessions, globals and FMS
                          TimGriffith

                          Global fields belong to the Filemaker client, not the server, and can be different from client to client, depending on their input.

                          • 10. Re: Sessions, globals and FMS
                            thosliot

                            Barbara

                             

                            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?

                             

                            cheers

                             

                            Tom

                            • 11. Re: Sessions, globals and FMS
                              BarbaraCooney

                              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.

                               

                              -Barbara

                              • 12. Re: Sessions, globals and FMS
                                Stephen Huston

                                Hi Barbara,

                                 

                                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.

                                 

                                Stephen Huston

                                • 13. Re: Sessions, globals and FMS
                                  BarbaraCooney

                                  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.

                                  • 14. Re: Sessions, globals and FMS
                                    Stephen Huston

                                    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.

                                    1 2 Previous Next