Thanks for responding...

>>Now to avoid the above, an idea that I got was to put the valid() call straight in the table using Field Validation Rule. Now the problem is that the actual validation is done in the BO.methods(), if I use a BO call here then I guess browsing through such tables outside the app will become impossible.
>
>You usually don't have to duplicate the same "validation rules" in the .Valid() events AND in the "save" routine.
>
>The "rule" that you would normally code in the "save" is: Is a required field missing ?
>
>If a field is optional, there is no need to "validate" it in "save" because the .Valid() would have handled it (had it been entered in the first place).

But what if the user presses Ctrl+S or clicks the Save button without completing the form (I have a muti tabbed interface)? There are numeric fields which default to 0 with a valid range including zero but not necessary 0. In such a case the user if shortcutted of missed a field in another form will get a wrong result saved.

>
>If the field is "required" and "missing" in the "save", then you just send Focus back to the missing field and the .Valid() will then pick up on it; a general message like "Field is required" is all that is necessary for any missing field ... the field that now has Focus is the one in error. (From a framework point of view, you simply return the field name; the framework interprets this as a missing field or a field in error and sets the focus).
>
>Is summary, "save" handles "missing" fields; .Valid() takes care of all the "validations" .... when performing "field level validation".
>
>If there are "cross-field validations", these can be handled in the "save" but can also be enforced by dictating a strict tabbing order in the UI by not allowing one to leave a particular field or to "arrive" (.When()) at some other field if a "previous" field(s) met some sort of condition. The User is always allowed to "back up" in the tab order to undo a set of conditions that might otherwise lead nowhere. As a user moved along, certain fields might also be disabled based on the present context; this eliminates having to "surprise" the User at "save" time by clearing or invalidating fields that are invalid within the context that the User chose (eg. male vs female; labor vs material; etc).