If at this point you then Revert Record and go back to the state before the data was entered in that field, I found that the data is still there meaning the Revert Record doesn't work.
That's because revert record reverts the record's uncommitted data restoring the record to the data present the last time it was committed. When you click the layout background you are committing the record and thus there is nothing left to revert.
But any validation errors should interrupt the commit record action and present you with the option to revert the record. This will not, however, roll back the serial number field's next serial value setting. Often such "gaps" in the serial number are not a major issue. The exception is when you need a gap free series of values for auditing purposes.
To make the validation process more user friendly, there are two options you can work with:
- Use the OnObjectValidate trigger to perform a script that responds to and processes possible errors before the validation rules are evaluated.
- Set up a group of fields with global storage specified. When a user clicks a save button on your layout, your script then validates your data and then, if all is valid, creates a new record and transfers the data from the global fields to the corresponding fields of the newly created record.
Ok thanks for clearing that up. Maybe it's something Filemaker should look at, as to me it doesn't make sense why there wouldn't be an option for the validation of an entire record, no matter how many fields are on that record.
Anyway, to keep it as simple as possible I guess option 1 you suggested would be best. Are there any threads or posts I could read up on this? As I wouldn't know where to begin with that script.
I don't have a link for such an example, but I can share this trick. With the OnObjectValidate, if you terminate the script with:
Exit Script [false]
Validation never occurs, the record is not committed and the user is returned to browse mode with the cursor/focus back on the field set up with the script trigger.
Thus, one simple scripted option is simply to show a custom dialog telling the user their error and when they click OK, it leaves them back in the field to correct the error.
@Phil Careful you don't let the USER ever have control inside that script, otherwise I think he can commit a record even though a single specific field in that record hasn't been validated. Also I think the Server can disconnect a USER on time and commit a record without validations. Thats kinda like a power failure.
@jim, this would be pretty much an "eye blink" script. Even without allow user abort [off], I doubt that anyone short of superman could successfully interrupt the script. It's basically just a way to show a customized validation error message in ways that the current validation message box in field options can't do.
And the server could only disconnect and commit the data "on idle" if this is set up as a permitted option in the user's privilege set, but definitely one to be aware of...
Thus, one simple scripted option is simply to show a custom dialog telling the user their error and when they click OK, it leaves them back in the field to correct the error
@Phil it was the Show Custom Dialog which MIGHT give USER control. Plus I have a accountant that can find any bug, she must be wonderwoman! I have a 10 year old tested DB that double accounted [last month] using GTRR and a found set being Changed by another rare action [not traceable on Debugger]. That took me 10 days to find that one because the FOUND set was Released during the accounting part.. The script was written prior to being put on a Sever. Thus, I wanted to chime in about Record commited and Releasing in a SERVER environment.
Yet the script looks like this:
Say you want to catch cases where a number less than zero is entered:
If [YourTable::NumberField < 0 ]
Show Custom Dialog ["Values entered in this field cannot be less than zero."]
Exit Script [False]
It's pretty hard to for any user to interrupt that script....