Database Reference
In-Depth Information
UP TO SPEED: THE PROBLEM WITH PROBLEMS
Although detecting problems up front is usually best, it isn't always possible. Sometimes you can't
find out about problems until your script has run partway through.
Most database systems handle this problem with something called a transaction , a chunk of work
that's held in limbo until you tell the database to make it permanent. In a nutshell, you open a trans-
action, and you then can do anything you want, but your changes don't get saved until you commit
the record. If you decide you don't want the changes after all, you can undo the transaction.
FileMaker uses this transaction concept under the hood to handle record changes, but unfortunately
you have no easy way to tap into the transaction system from a script. Here's why: When you first
enter a record—using the Open Record/Request script step, for instance—FileMaker begins a
transaction for you. When you exit the record— Commit Records/Requests —FileMaker commits
the transaction, writing all changes to the database. If you revert the record instead— Revert Re-
cord/Request —FileMaker essentially rolls back the transaction, leaving the database untouched.
Just remember that each transaction is linked to a record. For example, you can't begin a transac-
tion, then make changes to five different customer records and 11 invoices and then roll back all
those changes—you can only roll back the last one.
But if you create, edit, or delete records in portal rows while you're still in the record, all your
changes happen in one transaction.
Try this exercise in the Invoices file to explore how the transaction works. Have two windows open
(Choose Windows→New Window)—one showing the Invoice layout and the other showing the
Line Items layout. Create a new invoice record and add a few line items. Notice that FileMaker cre-
ates the new line item records when you add items to the Line Item portal on the Invoice layout. Be-
ing very careful not to commit the record (that is, don't hit the Enter key or click anywhere outside
the fields onto your layout), choose Records→Revert Record. The parent invoice record disappears,
and all the child line items disappear, too. You've just witnessed FileMaker's version of transac-
tions.
Knowing this, you can use the Open Record/Request script step on an invoice record and then
make changes to dozens of line items. Then if your script detects a problem, you can revert the in-
voice record and toss out all your line item changes as well. If you absolutely, positively must have
control over your transactions, arrange your scripts so they do everything through relationships from
one single record.
The If step doesn't need a fully realized test yet . Put a commented calculation ( Com-
menting in Calculations ) as your test for now, just to remind yourself what needs to be
tested. You can put the real test in later.
Add feedback by putting a custom dialog step in the True part of the If step . If you
don't give feedback here, the person using the database may get confused, since nothing
Search WWH ::




Custom Search