14 Replies Latest reply on Oct 15, 2012 4:47 AM by JeffHorton

    FileMaker Pro 11 not keeping up with AppleScript

    panders13

      Title

      FileMaker Pro 11 not keeping up with AppleScript

      Post

      I have an AppleScript that worked fine with FM Pro 10, but since I upgraded to FM Pro 11, it fails. The following example is a small portion of the script, but it fails consistently too.

       

      tell application "FileMaker Pro"

      go to layout "Layout1"

      do menu menu item "Show All Records" of menu "Records"

      end tell

       

      The "do menu" step fails with error: "Data is being accessed by another user, script, or transaction." (number -10011), which indicates to me that FM Pro is still performing the "go to layout" command when the "do menu" command is sent. I can add the following line as the first command:

       

      go to layout "Layout2"

       

      and the same error occurs, but now on the "go to layout "Layout1"" step. Immediately running the script again (with Layout2 already displayed) causes it to fail on the "do menu" step again.

       

      This error occurs several other places in my whole AppleScript, apparently whenever it involves changing the layout and immediately trying to perform another step.

       

      Does anyone know if this is an intended change in FM Pro 11, or a bug? Any suggestions for fixing or working around the problem? Right now I just have to re-run portions of the script to get my final results.

       

      Is there any way for an AppleScript to know when FM Pro is finished with a command?

       

      I am running on a Mac Pro with OS 10.6.2.

        • 1. Re: FileMaker Pro 11 not keeping up with AppleScript
          FentonJones

          I cannot reproduce this error. FileMaker 11, Mac 10.6.2. I tried on both a local and a WAN hosted file. Both worked. I even began editing in a field, in order to lock the record; still no error.

          • 2. Re: FileMaker Pro 11 not keeping up with AppleScript
            panders13

            I tried a few more things and have narrowed it down a little. My tables are fairly large, so I tried it with fewer records: still fails.

             

            Next I started with a brand new test database, with two tables: Stocks and Prices; Stocks has two text fields (stkSymbol & description), Prices has three fields (stkSymbol, date & price). Prices is related to Stocks through stkSymbol. I then created a new layout (Price History) based on Stocks with a portal containing the related records from Prices (sorted by date). I entered 2 stocks and three prices for each, then tried the following script:

             

            tellapplication "FileMaker Pro"

            go tolayout "Price History"

            go tolayout "Prices"

            go tolayout "Stocks"

            go tolayout "Price History"

            endtell

             

            It ran fine multiple times. Then I added a script trigger to the Prices and Stocks layouts to sort OnLayoutEnter. (The Sort script was set up to sort the Prices table on stkSymbol, then date.) The script gets the error consistently now on the "go to layout "Stocks"" step.

             

            It appears that the problem may be that FM Pro is still doing the sort when the AppleScript sends the next command.

             

            • 3. Re: FileMaker Pro 11 not keeping up with AppleScript
              davidanders

              When was the last time you saved the database as SMALLER, not clone.

              This is an optimization of the database that removes spaces in the database stack that are empty.

              On large databases, with many import or record creation and many deletions, this should be performed more frequently than fairly static databases, where records are not deleted often.

              BACKUP (as if you do not do this regularly) before doing this.

              • 4. Re: FileMaker Pro 11 not keeping up with AppleScript
                panders13

                I've never saved the database as SMALLER (I'll start doing that), but it isn't the cause of the problem. See my previous reply, where I was able to create the problem on a brand new database with only 8 total records.

                • 5. Re: FileMaker Pro 11 not keeping up with AppleScript
                  (O_O)

                  My suggestion is to add a delay step in your applescript.

                  Even a half second or less delay can help the matters.

                   

                  http://www.macosxhints.com/article.php?story=20040212081337914

                  • 6. Re: FileMaker Pro 11 not keeping up with AppleScript
                    panders13

                    Thanks for the suggestion, but I have experimented with it and the delay needs to be arbitrarily long to ensure that it always works, and that slows down the execution of the script unacceptably.

                     

                    I've tried something else that seems to work in my case, but might not in general. Since the problem I'm having involves the sorting when a layout is opened, I can check for the new layout to be the current one. By putting it in a loop with  "try...on error...end try," it will loop until the name is the correct one, then continue:

                     

                    tell application "FileMaker Pro"

                    set fdone to false

                    repeat until fdone is true

                    try

                    go to layout "NewOne"

                      if  (get name of current layout) is "NewOne" then

                    set fdone to true

                    end if

                    on error

                    set fdone to false

                    end try

                    end repeat

                    -- continue with script

                    end tell

                     

                    (I found that I had to put something in the "on error" section in order for it to work.)

                     

                    This is a bit of a bother to remember to include this code every time I change layouts, but at least it gets me around my problem. I do have to be careful and put the right layout name in the test each time, so I can't just copy and paste and go on. It also won't work in cases that might arise where a script doesn't know what layout to expect. In my case, that's not really a problem, but I can see the possibility arising in a case where the AppleScript tells FM Pro to execute an FM script, then sends another command to FM Pro. I have such a case in mine, but I know which layout the FM script will always leave open.

                     

                    As I said in my original post, this problem did not occur until I upgraded to FM Pro 11. The AppleScript has been running fine with FM Pro 10 for several months. So something in the way FM Pro interacts with AppleScript has changed. However, since I've come up with a work-around, I'm not going to spend any more time with it.

                    • 7. Re: FileMaker Pro 11 not keeping up with AppleScript
                      hiatts

                      TSGAL,

                       

                      I can also confirm that FMP 11 no longer waits for AppleScript to complete a step, even when using considering statements. The AppleScript just marches onto the next command, and usually results in an error. We have no way of determining if the FMP app is busy without adding additional flag fields to the database to confirm when FMP has finished its script.

                       

                      Could we ask for more detail on this sudden change.

                       

                       

                      • 8. Re: FileMaker Pro 11 not keeping up with AppleScript
                        martin.gardmark@grafia.se

                        Yepp, FileMaker 11.0v1 is an AppleScript disaster!

                         

                        FM ≤10 would "release" the AppleScript after recieving a "do script" command but not accept another "do script" until the previous one was executed. The trick then was to create a FM Script "doNothing" and call it directly after the actual script, thus making sure that the AppleScript would wait for FM to finish the actual task. A stupid but solid workaround.

                         

                        FM 11 however seems to accept multiple incoming "do script" commands in some multithread manner mening that the "doNothing" script will try to run in parallel and the workaround thereby is worked around by FM itself. Not good!

                         

                        If the AppleScript for example is created to import data to FM from a file and then delete the file, the result is disasterous.

                        We use a lot of AppleScripts and quickly downgraded our machines!

                         

                        If multiple scripts are run from within a FM 11 script though, everything will run nicely.

                        I assume that the problem is in the AppleScript API.

                         

                        We need a fix asap!

                        11.0v2 coming soon?

                        • 9. Re: FileMaker Pro 11 not keeping up with AppleScript
                          Flightmaster1000

                          Bump.

                           

                          This is a serious issue. As FM Server still cannot execute certain scripts (such as creating PDF's) we need to execute scripts from the iCal/AppleScript solution. Up until FM10, this worked great, but now all hell's broken loose. The fact that FM11 now accepts events w/o delay causes all manners of errors (as described above).

                           

                          Applescript script-launching from OSX is an important feature. Can we please be informed on when this will be solved -- or the FM even cares about this issue (I couid not find any obvious mentions of this issue in their documentation.)

                           

                          cP

                          FFG


                          • 10. Re: FileMaker Pro 11 not keeping up with AppleScript
                            jlg89

                            I agree, this is serious. It doesn't only affect multiple scripts triggered sequentially by AppleScript; I have a simple AppleScript that tells FMP to open a file, run a script, and then quit. The quit command causes the AppleScript to error, because apparently FileMaker tries to quit in parallel with running the script. Sheesh.

                            • 11. Re: FileMaker Pro 11 not keeping up with AppleScript
                              Carl_1

                              Well, it's been over a year, but there doesn't seem to be a resolution to this thread.  Has anything changed in FileMaker?  Has anyone come up with a good workaround for this?

                              • 12. Re: FileMaker Pro 11 not keeping up with AppleScript
                                JeffHorton

                                i had the exact same issue when upgrading to FMP 11, i had to use FMP 10 to circumvent the issue.

                                but now we are upgrading to FMP 12 and it is having the exact same issue, but cannot use lower FMP version to resolve this issue.

                                i did do those tricks explained below, but when you have 100+ applescript solutions it is going to be a great pain to do this to all of them and trap every kind of error.

                                • 13. Re: FileMaker Pro 11 not keeping up with AppleScript
                                  kdurrum

                                       Correct there is still no systematic resolution to this problem.  I ended up building a system handler and adding an additional field in my database.  There is a Get() Function that can retrieve the state of a record (assuming that the action you are attempting to perform and the previous action performed both access records).   The calculation you want to insert in a field is called: 

                                       Get ( RecordOpenState )

                                       I created a field with this Get() Function titled : record_access_status    (I ensured that the storage options were set to "Do not store calculation results).

                                       The applescript handler  looks like this:

                                        

                                  on WaitUntilReady(FMP9, myrecord)

                                  tellFMP9

                                        activate

                                        using terms fromapplication "FileMaker Pro"

                                        activate

                                        telltable "ad_master"

                                            tellrecordIDmyrecord

                                                set record_open_state to 1

                                               repeatuntilrecord_open_state = 0

                                               activate

                                                     try

                                                       setrecord_open_statetocell "record_open_state" asnumber

                                                     onerror

                                                        set record_open_state to 1

                                                            try

                                                               tellapplication "System Events"

                                                                     keystrokereturn

                                                               endtell

                                                            endtry

                                                     endtry

                                               endrepeat

                                            endtell

                                        endtell

                                       endusing terms from

                                  endtell

                                  end WaitUntilReady

                                        

                                        

                                       Of course, you need to modify the above applescript handler to suit your needs but the basics are in place.  I start with setting the record_open_state to 1.  I then drop into a repeat (loop) an attempt to collect the value of the contents of my record_open_state field.  If I am successful and the record is indeed not being accessed I should receive back a value of 0 (zero).   If this is the case then the repeat will exit and return back to the normal running script.  You want to place the handler call after your do script command.  For example:

                                        

                                        

                                  do script FileMaker script "insertPreview"

                                  delay 3

                                  my WaitUntilReady(FMP9, myrecord)

                                       I pass a few variables (FMP9, myrecord) into the handler to save myself time with rediscovering the ID of the record.  The FMP9 variable is used to declare my application version as I tend to run both Filemaker Advanced Application and Regular Filemaker Application on single station.

                                        

                                       The keystroke action was inserted to address error regarding File Locks.   On occassion I was running into an issue that was related to an external error message from Filemaker regarding the File being locked.  The only way I could find to get out of this was to invoke a system event keystroke.  As a result with each error I test to see if I need to invoke the return key... if not no problem but if I do then the error box will close.

                                       Inserting this action in my Filemaker applescripts has help me sleep easy at night.

                                  • 14. Re: FileMaker Pro 11 not keeping up with AppleScript
                                    JeffHorton

                                         Thanks for the write upsmiley, i'll need to try this approach.