Server Scheduled Script out of order

[Miss A!]

Hi there - Miss A! here.....

I have a script that search through records to find a record for a Tour with current date and create an invoice record(For that Tour) on the Invoice layout. When i run script through debugger it is ok but when script auto runs on server it creates invoice records for all tours in the tour list, even when there is no Tour with a current date.

See script in file attached, am unable to upload script within.

Please help - Many thanx,

Miss A!

 

 

Script.pdf

[Wim Decorte]

instead of checking for get(foundcount), check for error 401 after the find and exit the script.

[Kris M]

If the step

Set Field [ Tour_Storage::gt_Tour_Storage_Mail; Tour_Storage::gt_Tour_Storage_Mail & ¶ & ¶ & $Tour ] is executed by the server (PSOS or server scheduled script) and Tour_Storage::gt_Tour_Storage_Mail is a global text field it may not have the value that you think.

Are their any triggers firing on layout change?

instead of checking for get(foundcount), check for error 401 after the find and exit the script.

Wim,

Why would the 401 check be a better approach? Just curious because i use Get ( FoundCount ) in this manner all the time and have never experienced any issues with it.

Edited July 1, 2015 by Kris M

[Miss A!]

Hi Wim, i tried your suggestion but problem remains.

 

Hi Kris,

No Triggers at all,

 

 

The script is suppose to pass the first IF for no records found and just exit, but it don't do this - But in the Debugger it does just well.

 

 

[Kris M]

Seems like your script would do exactly what you expect..perform find and exit script if no records found.

As i said previously you should validate that the field Tour_Storage::gt_Tour_Storage_Mail is not a global because globals can not be found on....

http://help.filemaker.com/app/answers/detail/a_id/5895/~/working-with-global-fields

if its not a global then i would strip the script down to the bare essentials, insert error checking and run it on server via perform script on server to see whats happening.

Basically:

Go to layout

trap for and record errors if any.

enter find mode

trap for and record errors if any.

Set field 1

trap for and record errors if any.

Record the find criteria

Set field 2

trap for and record errors if any.

record the find criteria

perform find

trap for and record errors if any.

pass recorded values and found count back out of the server session with exit script.

Check the results

Edited July 1, 2015 by Kris M

[Wim Decorte]

 

Wim,

Why would the 401 check be a better approach? Just curious because i use Get ( FoundCount ) in this manner all the time and have never experienced any issues with it.

It's safer because it is more explicit about what you are checking for.  Say that you have a record load trigger on that layout or something else that is similar you may inadvertently create a found count.  Whereas your find will have produced error 401.  So the script as is will continue where it should not.

I've seen people shoot themselves in the foot with this.

It also allows to branch more easily based on error code (to capture for instance if the find requests are invalid, which is more info than just "nothing found")

 

Enter Find Mode

do some request

Perform Find

if[ get(lasterror) = 401]

  show something

  exit script

Else If[ other errors you want to check for]

  show something else

  exit script

End If

# if you are here you have a found set you wanted and you can continue

--> side benefit: the rest of a script is not indented into an IF that makes it sometimes hard to read and figure out where it all starts

[Miss A!]

Seems like your script would do exactly what you expect..perform find and exit script if no records found.

As i said previously you should validate that the field Tour_Storage::gt_Tour_Storage_Mail is not a global because globals can not be found on....

http://help.filemaker.com/app/answers/detail/a_id/5895/~/working-with-global-fields

if its not a global then i would strip the script down to the bare essentials, insert error checking and run it on server via perform script on server to see whats happening.

How does global affect performance even when the found set is zee - why not exit the script, instead it continues to loop through all the 332 records in the list for the Tours, plus it takes time when i observe on the server even on zero records found......I do not get it!

[Kris M]

If it found nothing it would exit so it is actually finding records.

you just have to figure out what it is finding.

i would just trust the line in the posting from FM that says You CAN'T use a global field to find records and find another way but that's just me.

How do you do a manual find for empty?

You set the field to "=".

What happens when you execute a find where their is empty string or null criteria.

Filemaker says give me something to search on.

If the global is empty, as it would be from the server context, you are telling the server to execute an invalid or incomplete find.

"=" does not equal NULL does not equal empty string ("")

You are suppressing errors with Set Error Capture ON and don't do any error detection and reporting as a script result so you have no idea what is actually happening on the server.

My guess is it either throws an error OR it is only executing the find where their is actual criteria.

Set some error capture stuff after perform find and see what error is thrown by the process when run on server.

If no error is thrown then the script is ignoring the set field for the global.

If an error is thrown then its probably 508 or 400.

When you PSOS you CAN NOT USE the debugger to watch the execution so you have to detect and pass values out of a script as a script result to see whats going on during execution.

Edited July 1, 2015 by Kris M

[Kris M]

It's safer because it is more explicit about what you are checking for.  Say that you have a record load trigger on that layout or something else that is similar you may inadvertently create a found count.  Whereas your find will have produced error 401.  So the script as is will continue where it should not.

I've seen people shoot themselves in the foot with this.

It also allows to branch more easily based on error code (to capture for instance if the find requests are invalid, which is more info than just "nothing found")

snip...

thanks for the explanation Wim. ill have to think about this a bit.

Are you suggesting that in between Perform Find and If (get (Found Count) > 0) a found set could be created by a trigger and that OnRecordLoad fires right after perform find in a script?

Edited July 1, 2015 by Kris M

[Miss A!]

Hi Kris M, 

I am not using a global field for the find, only for storing found Tour Numbers which i then send out in the email.

 

BTW - This script was fine a few months back until we upgraded to FM14 - Could this have anything to do with something?

[Wim Decorte]

thanks for the explanation Wim. ill have to think about this a bit.

Are you suggesting that in between Perform Find and If (get (Found Count) > 0) a found set could be created by a trigger and that OnRecordLoad fires right after perform find in a script?

Indeed.  I've seen it happen.  OnRecordLoad *can* fire immediately after a perform find if the active record changes.

It's just one of those instances where the developer's intentions as expressed in code do not necessarily explicitly match what he is trying to do.

[Kris M]

Ok my mistake on the use of globals in your script.

I would add the error trapping stuff i mentioned to see whats happening on the server during execution.

I would also trap for the found primary keys and send those back for examination as well because executing

Enter Find Mode [ ]
Set Field [ Tour_Details_TimetableVehicle::lxd_Invoice_Date_Start; Get(CurrentDate) ]
Set Field [ Tour_Details_Reservati::Final_chk; "Yes" ]
Perform Find [ ]

doing this find manually on client should result in the same found set as when it runs on server

Edited July 2, 2015 by Kris M