Update Types

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

Building Matchcodes

There are two ways to build a matchcode:

Logically

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.

Physically

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 stored 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 in the database when the first physically stored 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.

Update Types

Update Type A

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 utility. 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 most current data. This inaccuracy is usually acceptable when using the online search help.

Update Type S

The matchcode data is stored redundantly as a separate table in the system. The matchcode data is adjusted to each modification operation performed on the base 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.

Update Type P

The matchcode data is stored redundantly as a separate table in the system. The matchcode data is updated by the application program itself, so that this application program and other programs always have access to current matchcode data.

To do this, a function module MC_UPDATE_<matchcode_object_name> is generated when the matchcode ID is activated. The matchcode data is updated when the application program calls this function module.

Update Type I

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 in the database.

Update Type K

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