1. Write the rule before choosing an option
A field that looks correct on screen can still receive unsuitable data through a different route. Use this small exercise to compare manual entry, an import and a scripted commit. Work in a new local practice file, not a customer database.
Create Requests with Reference and Note as Text fields and Quantity as Number. Use no auto-enter values. The teaching rules are deliberately separate: Reference must be present; a supplied Quantity must be in the range 1 through 10. Quantity is not required in this first experiment. That distinction will matter during import.
A range allows fractional values between its limits. It is not an integer-only rule. Likewise, Not empty does not establish a trimmed, well-formed or unique business reference. Write those additional requirements separately before designing a production schema.
2. Make the settings inspectable
In Manage Database, open the field options for Reference. On Validation, choose Always, enable Not empty and disable the user override. Use a short static message such as “Enter a practice reference.” For Quantity, choose Always, enable In range from 1 to 10, and disable the override. Leave Not empty off for Quantity.
Record the configuration in the worksheet. Avoid calculated custom messages in this baseline so the exercise does not depend on that newer feature. A data-entry control guides input; an auto-enter option supplies a value; validation checks a rule. These are different jobs.
| Field | Practice setting |
|---|---|
| Reference | Always; Not empty; no override |
| Quantity | Always; In range 1–10; not required |
| Note | No validation or auto-enter |
This is a deliberately incomplete request model for learning. It is not a recommended production schema, and it does not add permissions or an audit trail.
3. Observe when manual entry fails
Create a request R001 with Quantity 2 and Note “Valid control,” then commit by clicking an empty area outside the fields. Confirm it remains after moving away and returning.
In a second record, enter R002 and Quantity 0. Leave the quantity field and record the message. Correct it to 3 before committing. Next try a new record with Quantity 2 but no Reference. Observe the result when you attempt to commit the record; cancel or revert the failed practice record rather than overriding the rule.
Field-exit checks and record-commit checks need different tests. Claris documents range checks at field exit and the required-value check at record commit. Do not decide that a blank reference was accepted merely because you could move to another field.
4. Distinguish a skipped field from a skipped record
Download the three-row import fixture ↓
Use a fresh empty copy of the configured practice file for this test. Import as new records into the existing Requests table. Identify the header row and map Reference, Quantity and Note. Do not create a new table from the CSV: it would not have the rules you configured.
| Reference | Quantity | Note |
|---|---|---|
| I001 | 2 | Valid control |
| I002 | 0 | Range failure |
| (blank) | 2 | Required reference failure |
Keep the original CSV unchanged. Read the import summary and inspect every accepted row. With the stated settings, the valid control should import. The out-of-range quantity demonstrates a field-level skip: other fields may import, leaving a record that still needs review. The blank required reference demonstrates a record-level rejection.
The worksheet records these as documented expectations to verify in your version. An import is not automatically an all-or-nothing operation. Retain the source, mapping, summary and actual stored values. A partial row can be unsuitable for business use even though the import completed.
5. Check writes and the commit outcome
After the manual test, review a small script that writes practice values and commits them. Capture Get ( LastError ) immediately after each fallible write and immediately after Commit Records/Requests. Use the existing error-handling guide for the result contract; do not continue a dependent workflow after failure.
For the baseline, leave Skip data entry validation off. Claris distinguishes Always validation from Only during data entry: the commit step’s skip option does not bypass Always rules. Turning dialogs off also does not prove a successful save.
Use one valid input and one missing-reference input. Record the stored values, saved error, caller result and whether a record remains open after failure. A failed commit is not the same as a deliberate revert. Decide whether the user should correct the pending entry or discard it, then implement and test that branch.
6. Choose a policy for incomplete data
Download the validation and import worksheet ↓
If your real request requires Quantity, add that requirement only after finishing the baseline and repeat the tests. Do not carry the optional-quantity experiment into production by accident. If all fields in a batch must succeed together, plan staging, review and an appropriate transaction workflow instead of assuming ordinary import validation supplies that guarantee.
Compare the results across manual entry, import and the script. Write down the exact version, rule settings, operation, error or summary, final values and recovery action. Test with intended privileges, without enabling full access as a workaround.
Finished result: evidence of which rule ran, what was retained and how the user recovers. These are generic desktop exercises. Native verification belongs in your practice copy before adapting them to a working solution.
FileMaker script example
This example requires FileMaker Pro 19.6.1 or later and no active transaction.
Create a Requests layout on the Requests occurrence with the validation options above. Start in Browse mode with no pending edits, no layout/record triggers and no auto-enter options in this isolated practice file. Pass one text parameter: valid, missing-reference or bad-quantity. Configure Commit Records/Requests with dialog off and Skip data entry validation off.
This example deliberately discards only the new test record if a write or commit fails. That is a teaching choice, not the recovery policy for an existing customer record. A successful call adds one record; repeated calls are separate tests.
How to use this: recreate the steps and their options in Script Workspace. This is readable script text, not a clipboard snippet or an importable script. These examples have been checked against documentation but have not been executed in a native FileMaker file.
Recreate these steps
FileMaker script
# Requests | Exercise validation
Set Error Capture [ On ]
If [ Get ( WindowMode ) ≠ 0 or Get ( RecordOpenState ) ≠ 0 or Get ( TransactionOpenState ) ]
Exit Script [ Text Result: "blocked: finish the current edit" ]
End If
Set Variable [ $case ; Value: Get ( ScriptParameter ) ]
If [ $case ≠ "valid" and $case ≠ "missing-reference" and $case ≠ "bad-quantity" ]
Exit Script [ Text Result: "invalid_test_case" ]
End If
Set Variable [ $reference ; Value: If ( $case = "missing-reference" ; "" ; "TEST-" & Get ( UUID ) ) ]
Set Variable [ $quantity ; Value: If ( $case = "bad-quantity" ; 0 ; 2 ) ]
Set Variable [ $created ; Value: 0 ]
Set Variable [ $cleanupError ; Value: 0 ]
Loop
Go to Layout [ "Requests" (Requests) ; Animation: None ]
Set Variable [ $error ; Value: Get ( LastError ) ]
Exit Loop If [ $error ≠ 0 ]
New Record/Request
Set Variable [ $error ; Value: Get ( LastError ) ]
Exit Loop If [ $error ≠ 0 ]
Set Variable [ $created ; Value: 1 ]
Set Field [ Requests::Reference ; $reference ]
Set Variable [ $error ; Value: Get ( LastError ) ]
Exit Loop If [ $error ≠ 0 ]
Set Field [ Requests::Quantity ; $quantity ]
Set Variable [ $error ; Value: Get ( LastError ) ]
Exit Loop If [ $error ≠ 0 ]
Set Field [ Requests::Note ; $case ]
Set Variable [ $error ; Value: Get ( LastError ) ]
Exit Loop If [ $error ≠ 0 ]
Commit Records/Requests [ With dialog: Off ]
Set Variable [ $error ; Value: Get ( LastError ) ]
Exit Loop If [ $error ≠ 0 ]
Exit Loop If [ 1 ]
End Loop
If [ $error ≠ 0 ]
If [ $created and Get ( RecordOpenState ) ≠ 0 ]
Revert Record/Request [ With dialog: Off ]
Set Variable [ $cleanupError ; Value: Get ( LastError ) ]
End If
Exit Script [ Text Result: JSONSetElement ( "{}" ;
[ "status" ; "error" ; JSONString ] ;
[ "error" ; $error ; JSONNumber ] ;
[ "cleanupError" ; $cleanupError ; JSONNumber ] ) ]
End If
Exit Script [ Text Result: JSONSetElement ( "{}" ;
[ "status" ; "saved" ; JSONString ] ;
[ "reference" ; $reference ; JSONString ] ) ]Run the valid case first and reopen its record. Then run each invalid case, saving the returned error and table count. Neither invalid case should return saved. If cleanupError is nonzero, stop testing and inspect the remaining edit before continuing. This script tests scripted writes and commit; it does not replace the separate import experiment.
References
Use a practice copy and verify the result in your FileMaker version. Product requirements and platform support remain specific to each product.
Filesoft counts page loads and selected resource and practice-download clicks in aggregate. These aggregate counts contain no practice data or visitor identifiers. Browser privacy signals and the site’s analytics-off preference disable these counts.