>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é