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.
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"
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.
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.
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.
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
go to layout "NewOne"
if (get name of current layout) is "NewOne" then
set fdone to true
set fdone to false
-- continue with script
(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.
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.
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?
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.)
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.
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?
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.
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)
using terms fromapplication "FileMaker Pro"
set record_open_state to 1
repeatuntilrecord_open_state = 0
setrecord_open_statetocell "record_open_state" asnumber
set record_open_state to 1
tellapplication "System Events"
endusing terms from
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"
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.