Jose,
Thank you for your reply. In regards to the business object you spoke of, can those rules be exposed to other applications. The reason I would like the rules at the database level is that I could program other languages against the back end and be assured that the data is not getting corrupted. Forgive my ignorance but I'm assuming that this is what automation servers are used for - to apply business logic to GUI front ends and data back ends. On another note I like your flaming red idea, I'm always on the lookout for graphical solutions for solving problems like that.

Mark



>>About a year ago I wrote about a problem I was having with some field validdations firing without a tableupdate() being called. I had just started working with VFP and figured it was something I was doing so I bagged the field validations and put the logic in the form instead (not the smartest thing to do). Well I'm starting to play around with extending the tables to other applications and would like the validations back where they belong - in the database. Summarizing, I have some fields in a data entry screen that cannot be left blank, in the DBC the field validations are !EMPTY(field name). In the form itself I have set up record level buffering. If I tab into the Editboxes and type something then delete what I type so the edit box is empty again and then tab out of the editbox the validations are firing and I receive a validation error. At first I thought it was the record level buffering because of its quirky behavior so I changed to table level buffering and get the same error.
>>I talked to an MS engineer who was able to reproduce my same error in VFP 3.0 and 5.00. When I asked what could be done his answer was to switch to SQL 6.5 as the back-end.
>>
>>The reason for this novella is for 1. Let everyone know of this behavior, as rare as it may be in case you run into this in the future and 2. Since I don't own VFP 6.0 if someone could test this out in 6.0 and let me know if MS fixed this or not.
>>
>>If anyone is still awake at this point I would appreciate any insight or suggestions you may provide.
>>
>>Mark
>
>Mark,
>
>I am still awake. For the exact same reasons you're describing I decided to drop the use of field rules at the DBC level. I now have my logic in the business object itself, in a BeforeSave() hook. Not a bad thing since you have much greater control on what happens and in which order. I have added some goodies like a find control utility that makes the offending control flame red for a while.
>
>José