Validations ARE carried out on Pre-Determined Join Fields
|Product/Release:||LANSA - All Platforms|
|Abstract:||Validations ARE carried out on Pre-Determined Join Fields|
|Submitted By:||LANSA Technical Support|
One of the great strengths of LANSA is the ability to add validation rules at the repository level for fields and know that these rules can never be bypassed. A predetermined join field is a virtual field just like any other virtual field. If LANSA were to ignore the validation rule for a virtual field that is a predetermined join field then this would be allowing the rule in the repository to be bypassed.
Imagine the situation where say another virtual field or a real field is derived from the predetermined join virtual field (e.g. first 4 characters are a company code). If the validation rule were bypassed for the predetermined join virtual field then this could result in blank or invalid data in the file for the derived fields.
There are two simple ways that this situation can be handled:
- The rule in the dictionary may be changed from ADD to ADDUSE / CHG to CHGUSE so that if the virtual field is not referenced on the INSERT / UPDATE (meaning it is not required to derive other fields or it has a valid default value) the validation rule is not applied. A rule of ADD / CHG is indicating the rule must be always applied for an INSERT / UPDATE.
- Use a different field name as the predetermined join field name. Eg. field FIELDJ that references field FIELD (but do not copy the validation rules). This is also a good convention as it is more obvious that it is a predetermined join field that is being referenced.