Thank you for your post.
When FileMaker Server opens a file for hosting, it is not opening the database as a client. FileMaker Server is merely acting as a conduit for the FileMaker Pro clients so that they can open the database remotely, so FileMaker Server itself does NOT run the On Open script when it opens the file. However, when the Script schedule runs, the thread that runs the schedule acts as a FileMaker Pro client, and thus runs the On Open (and On Close) scripts.
And there lies the problem. My "on open" script may need to use server incompatible script steps that abort or otherwise interfere with the performance of the scheduled script scheduled script even gets started. As far as I know, there is no way for the on open script to determine if it was launched because a human user opened the file.
Now that I think about it. Get(currentuser) probably returns a different value for a scheduled perform script thread than does a "client" machine no? And Get(accountname) may be even better. I'm not sure from what I read in the help file, but its worth some experimenting.
Well I ran the test I mentioned in my previous post and will now accept this post as a solution to the issue.
When the script is being performed by the server,
Get(username) returns the name of the script being performed.
Get(AccountName) returns Admin.
Thus the script step...
If [Get(UserName) = Get(ScriptName)]
should enable me to keep "Perform on Open" scripts from executing when a schedule kicks off a script for me.
When the script is launched by a server schedule, Get(UserName) returns the name of the Schedule, not the script.
If[Get(UserName) = "ServerScheduleName"]
is the effective test to detect whether a script is being executed due to a scheduled script or by a human user's actions.