The following changes occur when a physically stored matchcode ID is converted to transparent storage:
Search is case-sensitive
Searching via transparent IDs is case-sensitive. When entering a search condition, a distinction is made between uppercase and lowercase notation in text fields.
Size of the hit list can be reduced
The hit list displayed as the result of searching with 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 is used to search for an employee's personnel number on the basis of the employee's name and department. The base table contains data on the number and name. The secondary table contains the departments and their employees. There is no entry in the secondary table for employees who are 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 component fields
If component 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.