9 Replies Latest reply on Mar 13, 2017 12:21 PM by njem

    need to close window in server script?

    njem

      I need to understand windows in server scripts better. Had a long frustrating tracking down of a local script complaining "can't modify, open in another window". Found that if that rec was the last one modified by a server script, and since I didn't have the commit step, the record was still open. Silly me, I'd figured once the server script was done the record would be released, committed and released. Nope. It stays continuously open in some virtual server space. Okay, so I'll put commit at the end of any server script but still want to understand. I see that Open/Close Window are legit server steps. Huh? I'd just been doing Go To Layout, assuming the server script space had a virtual first window (just like when you open a file locally) and that when the script was done that virtual window and all connection to the file would close. Since without a commit, the record stayed locked, that makes me wonder, even if I commit is there still a virtual window open? Should a server script have Open and Close Widow steps? Or just a Close Window at the end to close the first default virtual window? Or maybe a Close File? And are there gotchas if a script created for local use (which may or may not have Window steps) if that script is called to run from the server? Confused.

       

      Thanks,

      Tom

        • 1. Re: need to close window in server script?
          Jason Wood

          From FileMaker Pro 15 Help:

          Running server-side scripts opens and closes the files that contain the scripts. Therefore, the OnFirstWindowOpen script trigger is activated when the script starts and OnLastWindowClose is activated when the script ends.

          So you shouldn't need a commit.

           

          By the way, the reason you might want to open additional windows during the script is for similar reasons that you might do it on the client - to maintain the context in your original window. You do not need to open a window at the beginning or close it at the end.

           

          Normally if another user (or server) had locked a record, you would get their username in the error message. Since you're seeing the "open in another window" error, that suggests either you really do have that record open in another window, or you have corruption... maybe try running recovery on the file?

           

          Has this been happening on multiple records or does the server script only operate on a particular record?

          • 2. Re: need to close window in server script?
            wimdecorte

            quarfie wrote:

             

            From FileMaker Pro 15 Help:

            Running server-side scripts opens and closes the files that contain the scripts. Therefore, the OnFirstWindowOpen script trigger is activated when the script starts and OnLastWindowClose is activated when the script ends.

            So you shouldn't need a commit.

             

            It may not be "needed" since the record will auto-commit when the session ends, but by not explicitly committing you are also robbing yourself from a chance to trap for and handle any commit errors....

            • 3. Re: need to close window in server script?
              wimdecorte

              njem wrote:

               

              Found that if that rec was the last one modified by a server script, and since I didn't have the commit step, the record was still open.

               

              I find that highly unlikely... Server does not keep any records open past the server-side execution.  How did you verify that server still had the record open?  Could you still see the session in the FMS admin console?

              • 4. Re: need to close window in server script?
                philmodjunk

                And unless you select the option to wait for completion, you might have a case where both client and server side sessions are trying to modify the same record due to the fact that the server side script is still being executed.

                • 5. Re: need to close window in server script?
                  Jason Wood

                  I was thinking it was a scheduled script, but if it's a "perform script on server" script... I wonder if that would cause the "record is being edited in another window" error while the server has the record open(?).

                   

                  Further, I wonder if you script has a pause or an endless loop and it isn't actually getting to the end? Check server logs.

                   

                  You also asked for gotchas when running a script on server - yes - you can identify incompatible script steps in the Script Workspace using View->Compatibility->Server. You also need to ensure you start with the correct context and you need to keep in mind that if you have an OnFirstWindowOpen trigger script, it will run first.

                  • 6. Re: need to close window in server script?
                    njem

                    Okay, so you guys being sure this didn't make sense I went back a dug deeper. I made an error in my debugging and looking for a locked record. There is a script that normally runs on the server but while I was trying to track down the mystery of the locked record, as an experiment I had the script run locally and forgot I'd made that change.

                     

                    But that brought up a different question. The script is actually in a related file. This has a front-end/back-end arrangement which I inherited and wish wasn't the case. So the front-end file, on a trigger, calls a script in the back-end file. If the back-end file isn't open (it normally wouldn't be) then it must be carrying out the script in a virtual window. With a little experimenting I found that this virtual window must stay open. If I make the script deliberately make a change and not commit it, then I can't edit that record in the front end. It's locked.

                     

                    I suppose the file is "open" in the sense that it's providing data as an external data source, but it's not open as in any windows open. But it seems to keep that virtual window open, and keeps a record locked even if the script ended.

                    • 7. Re: need to close window in server script?
                      philmodjunk

                      It's not a virtual window, it's a window. The window may not be visible to you, but that doesn't make it a virtual window. Any reference to the data file's data will open a window for that file in the background. Your back end file's script is simply using that window.

                       

                      The split file that you have actually can be very useful if implemented correctly. But scripts should not be performed in the data file unless necessary. The main reason for a back end script would be one that needs to be granted "run with full access" to modify data that cannot otherwise be modified.

                      • 8. Re: need to close window in server script?
                        wimdecorte

                        njem wrote:

                         

                        But it seems to keep that virtual window open, and keeps a record locked even if the script ended.

                         

                        A record will not remain locked because of a window, hidden or otherwise.  A record will remain open because it has not been committed or can not be committed (validation error, a trigger that does not exit as expected,..).

                         

                        So at the end of your workflow: do an explicit commit and add some error trapping and handling.  That should tell you if the record can not be committed and the reason why.

                        • 9. Re: need to close window in server script?
                          njem

                          wimdecorte, yes, should definitely have a commit, and as you've pointed out that also gives the chance to test for errors, but in general, if a window gets closed then any record that was open in it is committed (if possible) and unlocked? true? Not the way to do it, but this and the invisible windows that philmodjunk points out clarifies the picture.