The update type of a matchcode ID defines how the matchcode is built and how the matchcode is adjusted to changes in the data records of the Basis tables. IDs with different update types can be defined for a matchcode object.

There are two ways to build a matchcode:

The matchcode data is built temporarily when the matchcode is accessed. In this case it is implemented with a database view. This is called transparent storage of matchcodes.

The matchcode data is stored redundantly as a separate table in the system. You must define here how the data sets should be adjusted in these redundant tables to changes in the base tables of the matchcode objects.

All the physically implemented matchcode IDs of a matchcode object are stored in a table pool (called M_<Matchcode_object>). This matchcode pool is automatically created in the ABAP Dictionary and on the database when the first physically implemented ID of the matchcode object is activated. A pooled table (called M_<Matchcode_object><Matchcode_ID>) which is assigned to the table pool of the matchcode object is created in the ABAP Dictionary for each matchcode ID when a pooled table is activated.

The matchcode data is stored redundantly as a separate table in the system. The matchcode data is only built independently of data changes at certain times using the matchcode utilities. Since it could be quite time-consuming to build the matchcode data, you should do so at times when the system load is low, for example during the night.

When searching for a matchcode, it might not always be possible to access the must up-to-date data. This inaccuracy is usually acceptable when using the online search help.

The matchcode data is stored redundantly as a separate table and is adjusted to each modification operation performed on the Basis tables of the ID with ABAP Open SQL (INSERT, DELETE or UPDATE).

The matchcode data affected by the table change is therefore updated automatically without this being explicitly requested by the application. Automatic updating, however, results in a loss of performance.

The matchcode data is stored redundantly as a separate table in the system and is updated by the application program itself. This application program and other programs therefore always access the most up-to-date data.

A function module called MC_UPDATE_<Matchcode_object_name> is generated when a matchcode ID is activated. The matchcode data is updated when the application program calls this function module.

The matchcode data is implemented logically as a database view. Only transparent tables may be used in transparent matchcodes. When a transparent matchcode ID is activated, a view definition is automatically created in the ABAP Dictionary. This view definition contains the fields defined in the matchcode ID (in exactly the same order) and any defined matchcode selection condition as view selection condition. A corresponding database index should be created in user-defined matchcode IDs to support view access.

The transparent matchcodes are much more efficient than for example synchronously maintained matchcodes, especially for modification operations, since there are no extra database accesses, thus reducing the costs for communications with a remote database server in a client/server environment. The matchcode selection itself can be compared with the selection behavior of the physically stored matchcodes if there are suitable indexes on the database.

Classification matchcodes are user-specific search paths which, like all other matchcodes, can be accessed with the F4 help. However no matchcode data can be recorded for them (logical structure). Data is obtained from a function module, which must be specified in the matchcode ID definition and is called in the matchcode selection.