One of FileMaker's strengths is how you can update a live system immediately. Utilizing this strength, however, requires knowledge of what you can do safely and what you need to be more cautious about while working on a live FileMaker database system.

There are three areas to beware of when working on a live system:

• Table locking
• Users don't get new table occurrences (TOs)
• Throwing users on default tabs when saving schema/layouts

Table Locking

In FileMaker, table locking means that users cannot create records in a table. Even if you have the table locked, users will still be able to edit and delete existing records to their hearts' content.

The following scenarios will lock tables:

• Opening up Field Options on any field locks that table and it will remain locked until the Manage Database dialog is dismissed
• Adding, deleting, duplicating or renaming a field locks that table until Manage Database is dismissed

Other scenarios to keep in mind:

• Modifying (aka adding, editing or deleting) a table, TO or relationship does not lock tables. Only modifying fields locks a table.
• Modifying a calculation or summary field requires all records in the table to be unlocked to save Manage Database. This becomes a source of extreme pain the more users there are drumming away on a single table.

Of the 3 "gotchas" in working with a live system, table locking is the most disruptive. But, as long as you understand FileMaker's behavior in all scenarios, you'll be fine.

Tip: A table will only be locked if there's an on-creation auto-enter serial number in the table. You may consider using a universally unique identifier (UUID) via an auto-enter calculation field to avoid table locking.

New TOs

It's our experience that, of any changes made in a live system, the one most likely to fail to reach connected users is making new TOs. New fields, new scripts, new layouts, new value lists: Not a problem. New TOs? Usually a problem.

To guarantee that new TOs reach connected users, have everyone affected restart the FileMaker database.

Default Tabs

This "gotcha" is the least problematic from a will-the-application-run-correctly? standpoint, but it's arguably the most agitating from a user's perspective. Anytime schema or a layout is saved, any users currently on that layout will be thrown to the layout's default tabs (technically, that layout's control panels' default tabs). A bit jarring, just try to avoid making changes every 2 minutes.

The following scenarios will throw users on default tabs:

• Saving Schema (e.g. Manage Database, Privilege Sets) throws all users on the default tabs on all layouts, as long as you made some sort of change to the schema (i.e. FileMaker had something to save). Keep in mind that FileMaker thinks you made a change the moment you go into Field Options.
• Saving a layout throws all users on that layout's default tab

While working on a live system is generally advised against, the reality is that many times as a developer, you'll have no choice. Even then, updating a live system is more often than not the quickest and most effective way to get things done. Understanding how to safely update live systems will not only make you a better developer, it'll make the FileMaking experience more enjoyable for your users, too.