End FileMaker Transactions: the Endgame

Ending a FileMaker transaction is just as important as beginning it. Your script can’t just dribble off into nothingness after the records have been created or edited or deleted. The endgame should be strong. Below I describe how Karbon and the modularfilemaker.org transaction module works. Use any of all parts of it.

As I’ve described earlier, ending the transaction is about trying to commit the changes, reverting back if there’s any error anywhere in the process. Additional clean up can be done at this time as well. Let’s look at how to end a FileMaker transaction.

End the transaction script

In Karbon, we have an “End Transaction” script. It is called after the entire transaction is completed. In our case: when the Estimate and EstimateItems have been copied to Order and OrderItems. Here’s a basic version of the script.

Here’s the basic structure:

Set Error Capture to On
Commit Records/Requests step
Capture the error if there is one
Revert back.

Try to Commit

If all goes well during the actual ‘transacting’ steps (with a portal or without), the intended changes to one or more tables have been completed. Records might have been created or data in some fields of existing records was changed and all the records are held open in the computer’s memory. We now want to push the changes to the actual file and save the changes. So we commit. We try to commit.

The explicit step to commit the changes pushes those changes to the FileMaker file itself. It saves the data. The new records now show up in the file for other users, field values have been edited, and/or records are now gone for other users.

In this step, we also release ownership of any records owned by the transaction process (the newly created or edited record and the parent estimate record). We unlock it so that others may see the changes (edits or new records) and may do their own edits.

In FileMaker, the commit step commits all the records at once; there’s no order in which they’re committed, one after another. They all commit. We can then rely on this feature to ensure that ALL the changes were made in one instant.

The error of the ways

If the commit step throws an error, we then proceed to rolling back. What are those errors?

Well, since we’re creating records in this case, we’ll most likely get Validation Errors. We will get Validation errors if we are creating or editing records.

The rule is: If your commit would cause any Field Level Validation calculation to fail then your commit will fail.

Rollback changes

If there’s an error anywhere in the process, the transaction model allows the process to rollback the changes made. Since the changes made so far are held in the computer’s memory, any changes made are just discarded. They’re not saved to the file.

Changes that were queued up to be made can throw an error. We talked about that previously. So too can the Commit step here at the end. If there is an error anywhere, we begin the rollback.

In FileMaker we “Revert Record/Request”. This step reverts the current record and all the records changed during the transaction. In our example, if there’s an error and we “Revert” then this estimate and all its lines will not be copied into the Order Table.

ONE NOTE: If onRecordCommit is set on the starting context layout when the commit fails, the trigger will fail, and thus that script will not run.

Clean up

Once we’ve ended the FileMaker transaction, we can do other things to finish this whole process. If we’re using a context such as DBTransactions, then we can add information to the record that describes the success or failure reason of the transaction. In Karbon and in ModularFileMaker, we have a series of custom functions that get the error and report it back in a JSON object. This information is set into a field for later reviewing.