The weirdness of finds that return 0 records in server scripts

[WilliamCB]

Error capture is not compatible with running scripts from the server. (This is documented in the Help pages at http://www.filemaker.com/help/html/scripts_ref1.36.14.html but confusingly the step is not greyed out when you select "Server" for compatibility in the scripting window.)

Also, a find that returns 0 records will prompt an error that causes the script to halt when run on the server. Does this mean that I have to verify that any find will return at least one record before running the find? The bizarreness of this query makes me think I am missing something...

[IdealData]

The help page actually says

Set Error Capture

Purpose

Suppresses or enables normal FileMaker Pro alert messages

In other words, it cannot display alert messages in IWP or Server, which might be a subtle difference to actually trapping the error and taking appropriate script action, although I've not tested this yet - maybe you could do so and report?

[WilliamCB]

OK. So the error log reports this:

[color:red]2010-02-10 23:59:07.002 +0000 Information 645 fm10.test

Schedule "Daily rollover scripts" scripting error (401) at

"Content Daily Rollover Constrain Found

Set".

And error 401 = "No records match the request".

This script has the set error capture script step and runs fine from the client, even when the find returns 0 records.

Does this help?

[mr_vodka]

Could you post the script?

[WilliamCB]

Thanks! Screen shot of script attached. The problem is the Constrain step in the middle.

[Stage One]

Your script is not checking for any errors - although you are enabling error trapping, you must specifically check for FM errors in your script immediately after the script step to validate. You need some If/Else/EndIF constructs using the GetLastError function.

Basically, if GetLastError returns anything but 0 (zero) then it has failed and you should direct the script accordingly.

[WilliamCB]

OK. Will try that. Thanks v much.

Still seems a bit odd because clearly there will still be an error when the find fails, so I'd expect the script to halt at that point, rather than wait and see what the next step is!

[LaRetta]

When you turn on error capture, it is up to you to handle all errors. But are you aware that your script may not be finding the records you think it should? Your script indicates:

Insert Text [ table::closing_date; “≤” ]

Insert Calculated Result [ table::closing_date; Get ( CurrentDate ) ]

If you use your debugger, you will see that the ≤ is placed in the field but when the next step runs (the Insert Calculated Result), that the ≤ is overwritten so you are only finding records exactly matching the current date and not those that are 'less than or equal to'.

Instead of using Insert Text and Insert Calculated Result, it is recommended that you instead use Set Field[]. So it would be:

Set Field [ "≤" & Get ( CurrentDate ) ]

Why Set Field[]? The most Important reason is that Set Field[] doesn't require the fields be on the layout. Using Set Field[] whenever possible is very good habit to get into. :smile2:

[IdealData]

so I'd expect the script to halt at that point, rather than wait and see what the next step is!

All scripts will execute all script steps - regardless of any errors produced.

[WilliamCB]

1.

All scripts will execute all script steps - regardless of any errors produced.

I'm not sure what you mean here. The script, when run by the server, terminates when it finds an error, and sends us an email to say so. This is the nub of my problem. The email says:

[color:red]"FileMaker Server 10.0.1.64 on fm10.test reported the following event:

2010-02-02 23:59:21.406 +0000 Error 643 fm10.test Schedule "Daily scripts" aborted; unsupported script step.

Contact information not specified."

2. Yes LaRetta, I agree Set Field would be better here. Thank you. But this does work since the Insert Calculation step checkbox "Select entire contents" is unchecked.

[bcooney]

If User Abort is set to Off, then script execution will attempt to

muscle past non-server-compatible script steps. With User Abort set to On, any script error immediately aborts the script.