Kbase P25831: Dynamics. Validation and Other Schema Information.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/26/2003 |
|
Status: Unverified
GOAL:
Dynamics. Validation and Other Schema Information.
FACT(s) (Environment):
Dynamics 2.0A
FIX:
You should avoid using schema field validation, or at least you should not expect it to be executed in Dynamics applications. The Dynamics Object Generator eliminates the inheritance of schema validation in a generated SDO·s temp-table definition. This behavior occurs primarily because any reference to a CAN-FIND in a field validation expression will be compiled into a Viewer or other frame-based component built against that SDO. The Viewer is then not runnable without the database connected on the client, which is unacceptable in a WebClient deployment.
But beyond this constraint, compiling field validation into the user interface can cause other kinds of problems. In particular, the standard Progress frame behavior does not allow you to leave a field whose value does not pass the validation, even if you are generating a LEAVE event by pressing a button, for
example. This kind of stepwise field validation is generally not considered appropriate for GUI applications, where a user expects to enter data more flexibly and have control over whether to correct an invalid value immediately, before leaving the field, or not.
In addition, dynamically generated Viewers or other UI components (including those of a non-Progress interface) cannot use the schema validation anyway, so you can·t count on it as the primary mechanism for verifying correctness of your data. You should build field validation into the back-end business logic, where it will always execute.
You can use Lookups and Combos to enforce the kind of validation done by a CAN-FIND or by a validation expression that defines a list of possible valid values. These user interface components are more helpful in that they provide auto-completion and a list of values from which the user can select, rather than simply flagging an invalid entry and forcing correction before the user can leave the field.
On the other hand, specifying in the schema the appropriate values for field Label, Column-Label, and Format, as well as the VIEW-AS phrase for the field, is very useful. This determines the default look of any Viewer or Browser you build, and in the case of a dynamic Viewer, gives you the proper representation of all your fields without any coding or customization at all.