When to use PSOS

Today we continue our discussion of PSOS by considering when it would be advantageous to use it over performing the script on the client.

PSOS is better when…

PSOS is usually better when a script touches a lot of data. FileMaker is a distributed database platform – the client (FileMaker Pro or FileMaker Go) has its own database engine. These FileMaker clients do most of the work themselves. This means that the server needs to send the records to the clients to process. The major thing to understand here is that even if you only request one field, the entire record is sent (with some field exceptions). Each record that is updated also needs to be sent back to the server.

PSOS can also be used where a process takes a "long" time and ties up the user session. A wait longer than three to four seconds without any feedback can be considered "too long" for a user interface, and may lead to frustration and disengagement. That being said, users are usually accepting of longer delays as long as they know and that they have accurate progress updates.

Example: Touching a lot of records

Some processes need to find and summarise data from a large set of records. These summaries can then be stored in a table to centralise their use for reports and dashboards.

Let's consider the example of an aged care nursing home with four locations, each with five wings. A staff member working in any one of the 20 wings wants to access accurate data summaries in a dashboard.

We will start with simple counts of resident status: fall risk, high care, and medication alert.

The process to create the up-to-date summaries is as follows:

• Find all residents from the specified wing.
• Loop through each resident record.
• For each, determine each status from local and related data.
• Maintain a tally for each status.
• Store the final tallies for access by dashboard calculations and widgets.

As you can see this process touches a lot of records. It needs to first find a set of resident records. That may be up to 200 residents in a particular wing. Each record may have many related records that are used to determine each of the statuses.

The loop and processing will increment the numbers for each status in a standard JSON object:

{
 "campus" : "Annerley",
 "fall_risk" : 32,
 "high_care" : 26,
 "last_update" : "2026-11-02T08:53:37Z",
 "medication_alert" : 78,
 "wing" : "Rose"
}

This will be used to update the stored JSON for the specified wing.

The user will access the dashboard for their current wing. The dashboard will show the last update timestamp for the current data. If necessary the user can click a refresh button, which calls the update script to run as PSOS for the current wing.

This process works as PSOS because it accesses a lot of records. If this is run on the client these records would be sent over the network. Depending on network latency, this makes the process a lot slower.

In this case it is up to the developer whether PSOS waits for completion or not. I would probably opt for not waiting. The user will see the last update refresh when the PSOS script completes.

Let's continue with other considerations and observations tomorrow.