In this instance it showed error 100: File not Found. There you can get more details about any errors. To see what happened, I swithed over to the Log Viewer and enabled Server Events.
This failure showed in the Schedule view, under status – “FileMaker Script error”. When you separate the files, the server side script failed. This script worked perfectly when the files were in the same folder.
I then created a script in the UI file that found records in the data file through the External Data Sources. This will mimic a situation where running backups on the UI might differ from the data files. To test this issue, I took a copy of SeedCode complete, which uses three files, and split these into two folders, one for the data, and one for the UI. While relative file paths like file:filename.fp7 will still find other files, even across separate folders, they will break with server-side scripting across multiple files. Organizing databases into folders both gives a visual overview of separate types of files, and helps break down the backup process into more discrete parts. External File PathsĬonsider the server folder structure. Referring to these documents while setting up server-side scripting provides a nice overview of options and things to consider, but there are additional caveats. Where does the robot box sit? Is it a headless box in a server room, or on someone’s desk? If the robot goes down or fails, how quickly will this be noticed? What about backups? Moving the scripts to server might remove some of this concern.įileMaker’s Knowledge Base contains a couple of brief entries on server-side scripting, one defining the issue, another looking at differences between client and server-side scripting. Security considerations also play a part. The computer running scripts might be better served elsewhere. There are advantages to running regular tasks through Server. With enhancements in FileMaker Server 10 and 11, a veritable movement has risen in the FileMaker community to stomp out robot usage in favor of handling such events through FileMaker Server instead. This can off-load many tasks currently assigned to robot boxes, computers whose sole purpose is to connect to FileMaker Server, mimic a user and run various events. Yet aside from integration, FileMaker’s server-side scripting also runs native FileMaker scripts. This shows one of the many ways that FileMaker integrates with external systems, one of the great benefits of working with FileMaker. In an earlier post I wrote about FileMaker Server’s ability to combine system scripts, or shell scripts, with native FileMaker scripts.
0 kommentar(er)
