Considering scripts for the Web application

If you're creating a database for the Web, you need to take into account a few online quirks of FileMaker and online FileMaker users:

• Help users see changes in the browser. Add a Commit Records/Request function to the end of any script that modifies data, because the browser does not reflect changes to the data until the changes are sent to the FileMaker web server. Use this with the following types of functions: Cut, Copy, Paste, Copy Record/Request, and Copy All Records/Requests.

  Remember buttons, too. Append the Commit Records/Request function to the end of any button script that performs a data-modifying action instead of assigning a single script step to the button.

• Make sure Web-based users log out. You can add the LogOut function to a button to exit from the database application, or you can provide a script that performs this function. Due to the nature of how the FileMaker web server opens additional windows for various functions (sorting, for example), a session can't be terminated while windows are still open. Proper termination can occur only via the use of the LogOut button, your own custom script, or a session timeout.

If both Web-based and workstation-based computers will access your database application, you have a few other bits of functionality to think about:

• You can use the Get(ApplicationVersion) function to determine what type of client is using your scripts. If the value is FileMaker Web Publishing, you can execute scripts that are specific to use via the Web.

• If you have Web-incompatible statements, tell FileMaker to ignore them in your Web application. Add the Allow User Abort statement and set it to off in your Web-based scripts. This forces the FileMaker Web server to skip over incompatible script statements and continue execution. As a default, the FileMaker web server halts execution of a script if it encounters an incompatible script statement.

• You can use security accounts and privilege sets to specify which scripts a user can execute via the Web and thus use a specific set of scripts for your Web-based interface. See the “Putting Your Database on the Web” section later in the chapter for details on enabling security accounts and privileges. Chapter 11 explains your options for setting these privileges.