mac | pc open record when server script exceeds it's time limit

[dansmith65]

I brought this question up in Friday night chat:

 

What happens to a new and open/uncommitted record when a server side script exceeds it's time limit?

 

To clarify: I'm referring to a script that is configured to run with a specified time limit, as defined in the Server Admin Console.

 

And to be specific: I have a script that creates thousands of records in a single transaction. It creates the records in a portal and does not commit until the end of the script. When I validated the primary key as unique for the table that just had thousands of records created, it could take ~30 minutes to complete the commit record step. Since the script was only allowed to run for 30 min, when it went over the time limit the server canceled the script and as far as I can tell, committed the record, saving part of those thousands of records previously created, but not all of them. I have not definitively proved this is what happened, but this is my suspicion at this point.

[Wim Decorte]

Took me a while to test this, but I don't see the same behavior as you do.

 

My test setup:

 

- create a new parent record, leave it open

- in a portal create a number of related children

- at the end of this routine I have 6 open records (parent + five children)

- I then put FM in a counting loop that takes several minutes (still leaving the records open)

 

A server-side schedule runs this script but with a force abort after 1 minute.

After running the schedule, I do not see any new records created.

 

(All using FMS13)

 

So could it be that your script is committing at some point instead?

[dansmith65]

Thanks for testing Wim. I was having this issue with a database on a shared host, so I had limited ability to test/diagnose. I'm going to replicate this with a local server and will post back when I do.  FYI: the shared host was on FMS12.

[dansmith65]

ok, I finally got around to testing this and a new/committed record is saved when the script is aborted by the server via timeout (in FMS 12v5, at least).

 

In the attached sample file, run the "create records" script with a timeout/abort of 1 minute, wait for it to abort, then wait a few more minutes and you will see the records were created. If you don't want to run the test yourself, just watch the video I made while I was running the tests...

 

FileMaker Server aborted transaction script.zip

[Todd Geist]

Hey Dan,

 

Can you try it with the script set to Allow User Abort off?

 

Todd

[dansmith65]

I just tried it, but got the same result.

 

While I was at it, I did one more test where I disconnected the client that was running the server scheduled script and it acted like I expected: records were NOT committed.

 

Previously, I had assumed that the server aborting a schedule would act the same as when a user is forced to disconnect, but apparently it acts more like the Exit Application script step was performed. (FYI: I actually performed the same test with the Exit Application step in it, to confirm that the result is the same as an aborted script)

[dansmith65]

After further testing, a server-aborted script schedule does not trip the OnRecordCommit Trigger, so it's not quite like performing the Exit Application step.

 

To understand why this is an issue, consider this scenario:

You write a script to modify 100 records in a single transaction. If the server aborts the script after you have modified 50 records, those 50 records will be committed.

 

As of now, the only method I know of that will prevent this from happening is to add field validation to at least one of the records being modified. Have the validation calc test a value like $$ALLOWCOMMIT, which should be set to True right before the commit record step in your script.

(thanks for this idea Todd Geist)

 

In contrast to the above scenario, if a user is disconnected after 50 records were modified, those 50 records would NOT be committed.

 

FYI: Setting the layout to "not save changes automatically" didn't change this behavior.

[Todd Geist]

I can confirm this behavior on FMS Server 13v1.

 

The only way to prevent a commit is to use a Field Level validation.  Nothing else will stop it.

 

Todd