When stop is not really stop

From our discussions in the past few days, it is reasonable that a user may want to stop a process that is taking a long time or seems to be stuck in a loop.

There will be consequences

As we have discussed, just stopping a process dead may have small or major consequences.

The small consequence may be that the user is left in an unfamiliar state. They may be in a window they did not explicitly open, on a layout they have never seen before, with a found set of records they did not create.

In this situation, we can provide a “home” script that takes them back to the standard location they see when they start the database. This is useful because it returns them to a known state. However, it does nothing to restore the interface they were in before they started.

The larger consequence may be leaving the database in a state where you have part-processed record sets. The script may have imported records but not parsed them; it may have got part way through a loop to process imported records into live tables; there may be records created but not linked to the correct parent.

What we need to do is to provide the user with the ability to stop a process, and restoring their starting state. This is when the user says "Stop" and the script says, "Okay, I'll take you back to where you started."

Restoring state

There are two main tasks involved in restoring state.

The first is to take the user back to the interface where they started. The interface consists of:

• a specific layout,
• a found set,
• a sort order, and
• the current record.

There are a few approaches to doing this. The complex approach is to log all aspects of the interface before starting the process. Then we use that log to restore each of the components.

The simpler approach is to open a new window and run the process there. At the end of processing, the script can simply close that window. The starting interface is still there in the original window.

The other task may be to clean up the records. This is best done in a transaction. FileMaker transactions operate in a specific window, so it is often reasonable to start the process in a new window and manage the transaction there.

A practical approach

This gives us a practical way to handle cancellation.

Run longer processes in their own window so that the user’s normal interface remains untouched. If they stop the process, close the process window and they are immediately back where they started.

Where the process changes FileMaker data, use transactions as needed. If the process is cancelled or fails before it is complete, the transaction can be reverted, leaving the database as it was before the process began.

This does not mean that every script needs to be transactional. But when a process could leave partially changed data behind, we should decide in advance how it will either finish safely or undo its work safely.

The aim is simple: give users a way to stop a process without leaving them or the database stranded halfway through the ride.