When an application is being designed, one of the technical issues to be resolved concerns the use of primary keys, and when their values should be generated. If the primary key is classed as "Technical", it will not be displayed on-screen, and so its value cannot be entered by an end-user. Other types of primary key may be displayed on screen, but still generated by the system; often with these types of keys, application designers mandate that "gaps" in the key's sequence should not occur (i.e., each record should have a sequential key sequence - 1,2,3,4,5, etc., and not 1,2,4,5,etc.).

As an example, assume in an application a screen is used to create new customers. If the customer number is automatically generated when the user starts to create a new customer, its value will be lost if the user quits from the screen (and hence a "gap" will appear in the key sequence). If the customer number is generated only when the user attempts to store the data, it is not possible for such a gap to appear.

UNIFACE, however, has built-in primary key protection. If a primary key value is missing, UNIFACE will not allow the "Store" process to start (or even allow the user to leave the occurrence containing the missing primary key) as it interprets the field as mandatory. One way around this is to use the "On-Error" trigger to catch the missing value and allocate it at this point. This is not perfect, as problems can still arise following the "On-Error" trigger activation, and so gaps in the sequence could still appear. A better method is to force UNIFACE to ignore the fact that the primary key is mandatory. This is done by a specific use of the "LEN" syntax statement.

The example overleaf shows a component-level variation of the primary key "Cust_No" of the "Customer" entity. To avoid gaps in key sequences, the code to generate the primary key has been placed in the WRITE trigger. The screen-dump shows the correct Field Syntax to force UNIFACE to allow processing to continue (and validation to succeed) despite having a "null" primary key.

The "Write" trigger has a component-level variation such as;

if (CUST_NO.CUSTOMER = "")

activate "Key_Generator".generate_key("Customer", CUST_NO.CUSTOMER)
if (CUST_NO.CUSTOMER = "") return (-1)

endif
write

NB: If code is not added to the Write trigger to populate the primary key, a database error will occur.

Due to the fact that a component-level variation is required, it may be necessary to paint the primary key on a screen where it might otherwise have not been required. Use the "HID" field syntax to keep the field hidden from the user. The "LEN (0-0)" syntax has not been added at the model level to avoid potential problems elsewhere in the application.

This method is not only useful for avoiding key sequence gaps; to some application developers it is the "cleanest" method of allocating primary keys.

Copyright ©2000 OCS Consulting plc