A matchcode is a utility that helps you to search for data records stored in the system. Matchcodes are an efficient, user-friendly aid to locating records for which you do not know the key.
Example: You are required to enter the matriculation number (primary key) for a student in an input field, but only know the student's first or last name. With this information, a matchcode search allows you to quickly locate the student's matriculation number.
You define a matchcode in the ABAP Dictionary in two stages:
Example: You can search for a student's matriculation number using the student's first name, last name or address. The matchcode you require in order to be able to do this would, therefore, consist of the fields matriculation number, first name, last name, and address and of the tables containing these fields.
You could then define specific access paths for this matchcode object in the matchcode IDs. For example, ID 1 might describe access via first name and last name, ID 2 access via address.
In a matchcode object, you start by defining the area of the database to be used to form the matchcode by specifying the relevant tables and fields. A matchcode object is not stored physically, but describes a comprehensive logical view on one or more tables. You define the structure of this view by determining which tables are to be used in the matchcode object and specifying which foreign key relationships are to exist between these tables.
When selecting the tables, you first need to choose a primary table to which other tables can then be added. These other tables are then linked to the primary table by means of foreign keys. This link may be a transitive link. These additional tables are called secondary tables.
A matchcode object can have several matchcode IDs. The matchcode IDs are derived from the matchcode object by means of projection (field selection) and selection (specification of a selection condition). Matchcode IDs for a particular matchcode object are distinguished by a single character (letter or figure). Consequently, up to 36 matchcode IDs (26 letters and 10 figures) can be defined for each matchcode object. The figures 0 to 9 are reserved for matchcode IDs created by customers.
You can define a selection condition for a matchcode ID, which then functions as a filter for the matchcode to be set up. In this selection condition you can specify restrictions for all fields of the matchcode object.
Example: Only those students who took up their studies in the winter semester 1991 are to be included in the matchcode.
There are a number of different ways of building a matchcode:
If the data in one of the tables used in a matchcode ID changes, the matchcode records must be adjusted in line with these changes. The update type decides when this adjustment takes place. You specify an update type when you define a matchcode ID. A matchcode object can have matchcode IDs with different update types.
Possible update types are:
Update types for physically stored matchcodes:
Asynchronous to database changes (A):
The matchcode data is set up with the help of a utility program at specific times (e.g. overnight) independently of data changes. This means that the most current data cannot always be accessed. "Fuzzy" matchcodes such as these are acceptable for use as online search tools.
Synchronous to database changes (S):
The matchcode data is always set up simultaneously to a modification operation performed using ABAP Open SQL (INSERT, DELETE or UPDATE). The matchcode data affected by the change to a table is updated automatically without this having to be explicitly triggered by the application. However, this automatic updating does take time.
Updating within an application program (P):
The matchcode data is updated by the application program itself, so that this program and other programs always have access to current matchcode data.
For this purpose, a function module called MC_UPDATE_<matchcode_object_name> is generated when a matchcode ID is activated. When this function module is called by the application program, the matchcode data is updated.
Update types for logically stored matchcodes:
Transparent matchcodes based on views and indexes (I):
The matchcode data classified in this way is implemented as a database view. Only transparent tables may be used in transparent matchcodes.
When you activate a transparent matchcode ID, a view definition is created automatically in the ABAP Dictionary and on the database. It contains the fields specified in the definition of the matchcode ID (in precisely the same sequence) and the matchcode selection condition (if one has been defined) as a view selection condition. In the case of customer-defined matchcode IDs, a corresponding database index should be defined to support accessing of the view.
Transparent matchcodes are considerably more efficient than synchronously maintained matchcodes, for example, as no additional database accesses are required and, consequently, the volume of communications with a remote database server in a client/server environment is reduced. Matchcode selection itself is comparable with the selection behavior of physically stored matchcodes, provided there is a corresponding index in the database.
Classification matchcodes (K):
Classification matchcodes are application-specific search paths, which, like all other matchcodes, can also be accessed with the F4 help facility, but for which no separate matchcode records are saved. The application-specific search path is assigned to the matchcode ID by a function module. This function module must be specified when the matchcode ID is defined and is called when the matchcode is selected.