Recently there has been discussion in the FileMaker community regarding a known problem with live development (i.e., modifying database schema while other users are connected to the system). The problem is that under certain circumstances, the “New Record” command and script step will fail.
The aim of this article is to identify some specific circumstances under which New Record will fail, and also identify some specific circumstances under which it will *not* fail, and is based on a series of tests conducted using FMS 13v1 and a couple clients running FMP Advanced 13v3.
Disclaimer: These are preliminary findings and do not claim to be exhaustive or conclusive. If you are doing live development, you should test for yourself and draw your own conclusions.
Methodology: A system with two tables, Sales and Employees, was used. For all tests, the developer opened Manage Database and then did something (or in the case of the first test, nothing), but then did not click OK — instead the Manage Database dialog was left open. In no case was the “OK” button clicked.
Tests and Results
Note 1: I think of the entry circled in red as “Pandora’s Box”… once you’ve opened it (field options or calc defs), you can’t undo the mischief by simply closing it again — the closest you can come is to quickly cancel all the way out so that Manage Database is no longer open, thereby minimizing the time of exposure.
If you must view this information, a safer approach would be to select one or more fields, and then click the “Print” button like so:
Note 2: for the “Failure” scenarios above, if your user a) runs a script with a New Record step and b) error capture has been set to “on”, the New Record step will silently fail with an error code 303, which according to FileMaker Help means…
…and it’s not hard to envision significant problems arising under this set of circumstances, for example, a supposedly “new” invoice not being created, but instead an existing one being overwritten. To be clear, the error 303 will happen whether error capture is on or not — error capture will merely cause the failure to happen silently, i.e., without the “this operation cannot be performed at this time” dialog appearing.
Bottom line: it is the developer’s responsibility to trap for errors and ensure the data integrity of the systems they design and maintain. Common sense would suggest that if a developer (even occasionally) does live development, then error trapping around New Record should be part of the process.