>>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.
>
>You talked to a moron.
>
>>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.
>
>I haven't tested in VFP 6, but I am onfident that the behaior hasn't changed because I think this is the way it was designed. Rules that aren't meant to be enforced until a tableupdate are record level rules. Field level rules are enforced when the value is written to the field, buffering or not.
>
>>
>>If anyone is still awake at this point I would appreciate any insight or suggestions you may provide.
>>
>>Mark
>
>AFAIK, this is what field level rules are supposed to do, and this is why I don't like them at all. I have found it best to put these rules in a function called from the record validation rule, so the check is only done once. Forcing the user to enter fields in the order that
you choose is bad UI, IMHO, and this is what field level rules impose.
>
>In response to the other advise you have received, make sure you remember the difference between business rules and domain constraints. Business rules belong in the middle (or front if there is no middle), and domain constraints belong in the database. Jim Booth's website has a couple of good articles that pertain really closely to the questions you have. Check it out.
Erik,
In my case I am dealing with domain constraints. For field-level validation I was not aware that it was triggered even with buffering on. In my forms I was binding the data to the forms of which I have learned is not the correct way of handling data, I believe in my case I need to create middle-tier business rules. Thanks for the response.
Mark
Mark
