>I agree with this approach instead of using LostFocus or Valid. Another big advantage for me is being able to "read through" my error trapping in one location to be sure I haven't overlooked a case. That is a pain with individual error checking...
Indeed, it becomes extremely simple.
In fact, the DO CASE was only for illustration purposes; currently I use a table-based validation, with a special function that evaluates field [Rule] for all records that have [Table = ...] and, in case of a violation, accumulates a variable with the value of field [Spanish]. If there are only warnings (yet another field), the user is given the option to save anyway. If at least one error is a "strict error", the user can't save.
I also created a form to easily edit the rules.
In the latest incarnation of my "RecordValid" function (and the corresponding table), I added support for creating local variables through data in the table; that reduces repetitive lookups, and makes the rules easier to read.
I have managed to do most data validation with this generic approach.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
