Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Field and Record Rules
Message
 
À
20/03/1998 10:27:54
Stephen Bridgett
Stephen Bridgett Consulting
Gloucester, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00084678
Message ID:
00086153
Vues:
34
>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?).


Stephen,

First returning .F. from the rule code is the cause of the error condition, the error is Rule failed. If you return .T. from the rule code then there will be no error condition.

The problem with getting fancy in the rule code is that you are writing code that will run when VFP feels like running it. We can predict when the code will run but in truth we cannot dependably say that the rule for this field will always be evaluated before the rule for that other field in that other table. Therefore it is a good practice to only enforce field domain constraints within the field rule. Record domain constraints should be enforced at the table level rule. Unfortuntately we do not have a database level rule for inter table domain constraints, so this then becomes the job of the business logic object to ensure before any table updates take place.

At least for me, I have seen the tendency to initially use any new features as if they were some kind of magic bullet at first. This cause the misuse of teh feature and trouble. The validation rules provided in teh DBC are really there for the enforcement of specific domain constriants and if we try to get them to do more than that they start to get in the way.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform