>>Lets try this again. BTW, never check Rules of conduct after typing a long message, before sending it.
>>
>>I have a major problem with field and record rules. I may be overlooking something very basic however Microsoft posts 'work-arounds' on the knowledgebase so I think I'm on the right track. It seems that I (at least me) can't put up my own dialog (not Ok, Revert, Help) and fix the data problem without getting into a tailspin of errors (Invalid data type for example).
>>
>>If anyone would be interested in discussing their experience with the DBC field and record rules I would be very interested. And, as I am working on an end month deliverable, very appreciative.
>>
>>Thanks
>Stephen,
>
>A failed rule is an error and it generates an error condition. If you have an error handler you can trap for the error and give your own message. I wouldn,t change (fix) the error, I would change the value of the control to a vlaid value and make the user confirm the change.

Hi JIm

Yes but...
The beauty, in cocept, with rules is that the rule code, (hopefully stored in the DBC where it needs to exist only once) is permitted to intercept an error that the row or field message option is going to make public. In fact, the rule code is an 'optimistic' error handler. That is it will handle but doesn't necessarily expect an error to occur. In principle its great. In practice it just doesn't work out to be that simple. Stop me if I get on a rant, Im following a line of thought here :). Seems to me if the rule code finds an error situation it should correct it and the message side should just make the deed public when the rule returns .F. That works to a point, simple replace field x with y is achievable but if the rule code gets at all fancey, ie involving other tables, then things come unglued quickly. I can't get past the quezy feeling that something just isn't right down there 'hold'. What do you think (eh?).