Effect of Conversion on Transparent Matchcodes

The following changes occur when a physically stored matchcode ID is converted to transparent storage:

Searching via transparent IDs is case-sensitive. When entering a search condition, a distinction is made between uppercase and lowercase notation in text fields.

The hit list displayed as the result of searching via a transparent ID can be a genuine subset of the hit list found with an equivalent search via a physically stored ID. The reason for this is that the access with transparent IDs is implemented using an inner join, while, with physically stored IDs, an outer join is formed.

When you search via a transparent ID, records of the primary table for which there is no corresponding entry in the foreign key fields of a secondary table are not found.

An ID implements a search for an employee's personnel number on the basis of the employee's name and department. The Basis table contains data on the number and name. The secondary table contains the departments and the members of the departments. There is no entry in the secondary table for employees not assigned to a department. These employees cannot be found using a transparent ID with the fields for the number, name, and department. However, if a physically stored ID with the same structure is used, these employees will be found.

· Adjustment of sub-fields

If sub-fields were defined for the ID, these definitions must be canceled when an ID is converted to transparent storage. You can return the output list to its previous format by changing the layout.