When to use PSOS (cont.)

Yesterday we looked at a typical use for PSOS: moving a process that works with many records to the server. This can reduce network traffic between the client and host, and it may make a long-running process feel more responsive for the user. The actual performance gain depends on the process and the server’s workload.

Today we will consider a few other good uses for PSOS.

Delete a large batch of records

Clearing a temporary table before starting or continuing a process is another common task. If a client-side script uses Delete All Records, the repeated communication with the host can add significant overhead. Running the process with PSOS may reduce that network overhead by doing the work in a server-side session.

If the goal is to empty an entire table, FileMaker also provides the Truncate Table script step. It deletes all records in the specified table, regardless of the current found set, and may be faster than Delete All Records for a large number of records. Truncate Table requires Full Access privileges. The easiest way to ensure this is to grant the PSOS script full access privileges. Also be aware that Truncate Table does not delete related records, so choose the method that fits the task.

Use server-side resources

There are times when a server has access to resources that the client does not. One case may be a shared storage location. When the client may not have a connection to that location, any documents or outputs that need to be stored there will fail. Be aware that the server can only access the Documents folder and a temporary folder. Files should therefore be output to the Documents folder, and a plugin or OS-level task used to move them to a shared drive.

Another example is a plug-in installed on the server only. The advantage here is that the plug-in does not need to be installed on every client. Some clients, such as FileMaker Go and FileMaker WebDirect, cannot use plugins directly. To access the plug-in features, a script needs to run on the server.

Running a process with PSOS solves these problems. The server will always have access to the Documents folder or correctly configured plug-in, and therefore can complete the process successfully.

The caveat here is that you must be aware of any server-side limitations in script steps. These limitations have been greatly reduced in recent versions with more script steps being fully compatible running server-side. We will talk more about this in a later post.

What do you use PSOS for?

Is there a compelling reason or scenario where you use PSOS? Let me know by email and I can include it in a future post.