>>>In my opinion, this is the way to do it...a global error handler should be set-up and this is one of the errors it could handle....
>>>
>>>Joe
>>>
>>>
>>>>Try using an error handler
>>>>
>>>>on error do errhandler()
>>>>
>>>>errhandler()
>>>>
>>>>if error() = 1582
>>>>
>>>>
>>>>endif
>>>>
>>>>
>>>>1582 I think is the error number for a field validation error. You can check in the help contents of Visual Foxpro under the Technical Reference.
>>
>>Excuse me on this, but is this not a non-oop way of handling it?? I would think the form or whatever is doingthe update to the table/column should handle the error as apposed to GLOBAL error handler..
>>
>>Am I wrong here??
>
>
>You're correct. The error should be handled by the object.
Um...pardon my backwards foolishness here...but how about taking it out of the hands of both the object and the error handler?

I handle all of my application validations with an OLE Automation object, which I instantiate at the beginning of all my apps (and when I'm working in VFP, as part of my startup PRG). The OLE object does one task...it uses a parameterized view (or a SELECT, if you prefer) to query a table full of rules/validations, applies those rules in the desired order, and returns a pass/fail. Obviously, if there are no validations in the table for that item, the OLE object returns "pass".

This accomplishes several things. It's truly OOP, because you only code a validation once (when you put it into the table). Since the actual code performing the validation is kept in a simple VFP free table, It's easy to write a tool to maintain these validations. More importantly, it *centralizes* all of the validations for ALL of my development in a single location (I keep that table in the same place I keep my development-level classes, so it's always in the same location). I can compile all or part of that table directly into an application). And it's scaleable, if I ever need to, simply by making the view remote instead of local and upsizing a free table.

For this particular case, it would also make the creation of the message the resposibility of the piece of code that messages the OLE automation server. This means that the user can handle a failed validation however they want.

Just another approach...but if anyone's interested, I'll be glad to share this. It's really trivial...took me about two hours to get it working.

Evan Pauley