Scheduled script aborting for some reason...???

[angelleye]

I've got a very basic script that loops through all of the records in a database and updates 1 field (indexed) with the value of another (non-indexed) calc. field. This it to improve performance from PHP API web apps.

When I run the script from inside FM Pro myself it works just fine. When I setup a schedule to run the script it says "running" for about 30 seconds and then says "Script aborted" without any information as to why.

Any ideas would be greatly appreciated. Thanks!

[LaRetta]

Have you made sure every script step is web compatible (use the checkbox at the bottom of the script list).

[angelleye]

I just took a look and the only thing in there that wasn't web compatible was a freeze window step at the very top.

This script, though, isn't being run from the web and there are no other scripts being run from within it. It's about as simple as it gets.

Go to Layout["CW__Inventory" (Inventory)]

Show All Records

Go to Record/Request/Page[First]

Loop

   Set Field [inventory::QTYAvailableIndexed; Inventory::Qty_Available]

   Go to Record/Request/Page[Next;Exit after last]

End Loop

I'm simply trying to populate/update an indexed field because the calculated fields make web applications extremely slow. Again, though, this script itself has nothing to do with the web.

[angelleye]

Well, I did go ahead and remove the Freeze Window step at the top and this time it simply says Script error. No other info. I can run it perfectly fine inside FM Pro, though.

[Steven H. Blackwell]

Does the Account under which the script is run have privileges to do what it is asked? Check the logs for more information.

Steven

[LaRetta]

When you say you are running it via a schedule, do you mean FMS? You can look at your event logs and it will tell you why you got the error. Also try adding error capture and see which error number is thrown.

One of the problems with server-side scripting is an inability to run it through debugger like any normal client. I would suspect permissions ... the Account and Login you specify on a server-side script must also have permissions in your script steps.

UPDATE: WOW - was I slow!

Edited August 3, 2008 by Guest
Added Update

[angelleye]

I've been trying it with admin so the privileges shouldn't be the issue.

I'm looking at the event log now and it does provide some more information but I'm still confused.

scripting error (4) at "Inventory : Startup : Adjust window"

scripting error (101) at "Inventory : UpdateQTYIndexed : Go to Record/Request/Page

The script doesn't have any steps for adjusting windows so I'm not sure what that's about and I also don't know why it would have a problem moving to the next record when the step before it is Show All Records.

This is the first time I've ever tried to setup a script from inside FMSM. I didn't think there'd be any special trick to it. This is about as simple a script as it gets. 1 File, 2 fields in the same table.

Can you shed any light on those errors for me?

[LaRetta]

I didn't think there'd be any special trick to it.

We are learning that there are many tricks and gotchas; I hope a lot was discussed at DevCon about it.

Error 4 is Command is Unknown. That Adjust Window is web compatible and I believe that is why the error is being thrown because (we think) server side scripting uses the web piece (is this the Freeze Window spot as well?). 101 is always thrown because it can't go to the next record, DOH. It seems that the logs show errors even though we trap for errors on the client side. I sure hope FM allows suspressing unnecessary errors such as 101 because it shouldn't be considered an error.

I am hoping that FileMaker enhances server-side scripting and provides us more tools for debugging and some good documentation about the behaviors we can expect.

[LaRetta]

You say the script doesn't have Adjust window but that is not the error point:

"Inventory : Startup : Adjust window"

Look at your startup script.

[angelleye]

Good call on the Startup Script. I didn't even think about that. It did indeed have an adjust window step in it.

I simply disabled the startup script for this file cuz we really didn't need it anyway. Now I'm still getting the 101 error when I try and run the script via FMSM.

Why would it not be able to go to the next record? I'm just showing all records and then beginning to move through them.

[LaRetta]

Just because you are getting the 101 error doesn't mean the script won't go to the next record. As I said, server-side script throws that error even though it works and it is something which I hope they eliminate.

Are you still getting script aborted or script error? If so, I would still AGAIN suspect permissions. Within FileMaker Server, permissions must be set ON THE SCRIPT when you create the schedule for it. Are you sure it is set to Admin there as well?

[angelleye]

Actually the Script Aborted error stopped when I removed the Freeze Window step. Now it just says Script Error and the log shows 101.

[LaRetta]

I've been trying it with admin so the privileges shouldn't be the issue.

It depends upon WHERE you checked for those privileges! For server-side scripting, you must (from with SERVER ADMIN CONSOLE) specify Account and Password for the script (when you set it up or edit it) so it shows Account: Admin there - just as Steven also said!! Did you?

Simply, you are right in that your script is very simple and you shouldn't be getting a script error. Privileges is the only thing it COULD be unless there is something else going on in that script or file that we don't know about.

Sorry I can't provide any other ideas. :crazy2:

[Baloo]

When you get to the last record in a found set go to next record throws the "Record is Missing" error. While the client ignores it (and probably uses it as the trigger for "exit after last"), the WPE records the error.

[LaRetta]

Right. That's what I'm saying ... the 101 isn't an error when generated in the logs through server-side scripting. So that can't be why the Script error message is being thrown in the Admin console; something else must be causing it. It sure has me stumped on what else it could be. :idunno:

[xochi]

I've taken to adding extra checks to loops, to avoid spurious errors. e.g.

Loop

   Exit Loop If (Get(RecordNumber) = Get(FoundCount))

   Go to Record/Request/Page[Next;Exit after last]

End Loop

It's annoying we have to do this, and it probably costs a little in performance.

[Baloo]

Actually, I'm saying it is an error that's thrown by the db engine, but that the client generally ignores it. You can trap it in a script run by the client if you turn error checking on. It's just not a fatal error so whatever is driving the server side scripting (ostensibly the WPE) records it and moves on.

[LaRetta]

Hi, Baloo! Yes, I understand why 101 is thrown and I understand that server-side scripting is handled by web publishing engine (I think). It is a natural error that is ALWAYS thrown except clients suppress it with error capture and server-side script does not. And that's what I've been saying if you read back up through the thread so I'm unsure what you see so differently than what I've said.

But it feels like you are missing my point as well - 101 isn't a problem!! DrewAngell's script should still run perfectly fine even if the logs show error 101. Getting the 'Script Error' message instead of the 'OK' in the Scheduled Admin Console is NOT fine. It means the script did not execute properly.

As for the 101 error, FM should suppress this error message (if the Account = FM Server) because it causes the exact confusion being experienced here by people beginning to use server-side scripting. And it also bugs people like Xochi and I who like lean, clean logs and dislike wading through errors which aren't really errors.

Hi Xochi!! Well I suppose it is workable. But I'm hoping FM will just fix it. Sure as anything, if I change these scripts (and there are several of them) then FM will fix the issue. It is an Eddie Murphy, Jr. law.

[tgilders]

Getting the 'Script Error' message instead of the 'OK' in the Scheduled Admin Console is NOT fine. It means the script did not execute properly.

Hi LaRetta and all,

Something to note as to why the admin console reports "Script Error" rather than "OK" in this scenario: If the very last "error-able" executed script step generates the error, then the admin console will show "Script Error", otherwise, it will show "OK". In this case, it's the "Go to next record" step.

Simply add a Set Variable step after the loop (something like $Done = 1) and you will get the "OK".

[LaRetta]

Oh wow. Well ya all know we shouldn't be having to do any of this. I was told they'd be coming out with documention on server side scripting and as yet I have seen nada. I was told by an FM system engineer that they probably wouldn't be coming out with anything about it; at least not now.

Thank God we have FM Forums where we can share information such as this.

So the bottom line is ... Script Error might NOT be a problem but how do we know? Question is: did the script run correctly? We still haven't heard back from DrewAngell as to whether the script bombs or whether it writes those Set Fields[] as it should.

And there are still many more questions and uncertainties than answers on the subject. As I've said before ... server-side scripting is a client that doesn't behave exactly like a client. And we [color:red]SHOULD have documentation to explain all of the subtle (and not too subtle) differences. I guess we'll discover them as we stumble over them. :crazy2:

Edited August 7, 2008 by Guest
Corrected - I had left off the word SHOULD and it makes big difference

[xochi]

Veering a bit off topic here -- I'm like La Retta in that I don't like non-error errors in my logs.

Another frequent one I've encountered is the "find for certain records : zero found" issue. If you are trying to process only a subset of records that meet a certain criteria, the natural thing to do is to find for those records. However, if no records match, you'll get the error.

So, clever me, I figured I'd just invert the find -- find for only records that don't meet criteria (of which I know there will always be at least one) and then Show Omitted, and the remaining records will be the ones I want, and no errors will show up in the log.

Brilliant!

One hitch -- it turns out that the find/show omitted steps are non atomic, which means that if another user creates a record between those two steps, suddenly that record appears in the "omitted" set and gets processed.

This bug just bit me this week. In hindsight, of course there's no guarantee that find followed by show omitted would operate atomically, so I went back to the old method and am trying to live with error messages in the logs :P

[LaRetta]

It sounded good as you were explaining it too! I suppose you can loop, something like (pseudo script untested):

... after perform find ...

Set Variable [ $foundCount ]

[color:red]Show Omitted Only

Loop

Exit Loop If [ Get ( TotalRecordCount ) - $foundCount = Get ( FoundCount )

Perform Script [ this find script ]

End Loop

But why oh why do we have to produce Dog & Pony. I suppose it's to give me something to complain about. :wink2:

Edited August 8, 2008 by Guest
Add Show Omitted Only

[LaRetta]

Well of course I forgot the Show Omitted Only. But I think you know what I meant. I've corrected the script above. :wink2:

[Max Heller]

I have used the following to get around this error:

Go to Record/Request/Page [First]

Loop

    Exit Loop If [ Get ( FoundCount ) = 0 ]



    ...



    Omit Record

End Loop

Edited March 18, 2010 by Guest