Data Validation Using Matchcodes

Another useful way to maintain data integrity during user input is to use matchcodes. A matchcode is an object that is used to find data records in the SAP Data Dictionary. More specifically, matchcodes access data records in a way similar to an index in that all key fields are not necessary, but they differ from indexes in that matchcodes can contain more than one table in the selection range.

Here's how it works: First a matchcode object is defined with the pertinent primary and secondary tables and significant fields designated. This object then identifies all possible paths to the required data records. Next, matchcode IDs are created by mapping one path defined by the matchcode object. The only data fields that are allowable in this ID are based entirely on the matchcode object. At least one ID must be declared for each matchcode object. Matchcode objects are stored as a table pool, which is automatically generated for each matchcode ID that you declare.

A data pool is a logical pooled table that is used by SAP to internally store control data. This data, which is not pertinent externally, is mapped as a number of database tables to one SAP table.

A matchcode can be assembled in two different fashions:

Physically. In this setting, data is stored in a separate table in the SAP system. Update types A, P, and S are maintained in physical tables.

Logically. This option sets up matchcode data temporarily on access to the matchcode. This access is managed by a database view. In this respect, the logical method is the same as transparent storage. This includes update types I and K only.

In the following task, you will learn how to follow 12 easy steps to create and maintain matchcode objects. Start at the Data Dictionary screen and complete the following steps:

The initial screen of Data Dictionary.

Enter a name for your new object, click on the Matchcode radio button, and press the Create button.

Enter descriptive text as you enter your primary table on the Attributes screen and press the Save button. The primary table represents the primary source table for the subsequent field search. Secondary tables can also be maintained at this point by double-clicking on the primary table or pressing the Tables button. These tables must link to the primary table through foreign keys.

At this point you have the option of creating the matchcode as a local object or attaching it to a transport request. After you have done this, click on the Save button .

As the status bar reflects, the mandatory key fields are transferred automatically If you want, you can press the Fields button and maintain any selection fields you want. At this point you need to click on the green arrow to go back to the Maintain Attributes screen.
The next step in the creation process is to activate the matchcode object. The status of the object is New and Saved .
The status is now set to Active and Saved. Next you need to create a matchcode ID or your object will be incomplete. To do this, click the Matchcode IDs button.

The system will prompt you to create a new ID if one does not exist . To do this, click on the Yes button.
On the Create Matchcode ID screen shown in Figure 21.9, specify a matchcode ID number, valid input ranges from all of the alphabet, and any number. You can also click on the down arrow to view a range of valid entries.

The Create Matchcode ID dialog box.
Let's view some possible entries . As you can see, this list window shows a number of matchcode IDs and a short description of each. Choose one and click on the green arrow.

A Matchcode hit list.
Follow these steps we learned to maintain selection fields for this matchcode ID, be sure to enter an Update type, and click on Save . I will further discuss Update types later in this section. At this point, you can enter further selection criteria by pushing the Selection Criteria button.

Maintenance of matchcode attributes.
In the Maintain Selection Conditions screen, you can enter and maintain fields and selection criteria for your matchcode IDs. Here is an example of a requirement of a Material Number not greater than the value of 8888 . When finished, click Save and the green arrow to go back.

The Maintenance Selection Conditions dialog box.
Now all you have to do is activate your matchcode ID and your new object is ready to use.

Generate and use the matchcode.

NOTE
The Index sub-screen doesn't need to be maintained because these characteristics are merely for documentation purposes in the current version of the SAP system. Just leave this blank and ignore the subsequent warning that appears in the log of your object activation.

In those 12 easy steps you created a matchcode that you can now use for maintaining data integrity. You learned how the primary keys help you check possible values of linked tables and the concept of a pool of data fields. Remember, the manner in which the matchcode data is arranged varies according to which update type is selected during initial creation. Here is a description of each of these five types:

I-Arranged by the attributed database.
S-Arranged by the database interface.
A-Auto-arranged by the system program SAPMACO.
P-Arranged by an application program.
K-Also arranged by an application program.
Syntax for Using a Matchcode
The following is the syntax for using matchcodes for selection screen parameter input validation:

tables: saptab
parameter: example like saptab-field matchcode object exam.
select single field from saptab where field = example.

This example uses the matchcode object exam, which has already been defined with a matchcode ID, to validate the data input into the parameter field example. This object exam holds the relationship data necessary to maintain the integrity of the user input.

Click Here to Read More !!!!

Data Validation Using Foreign Keys

The SAP environment's relational data model can contain many tables, views, structures, and linked tables. Foreign keys, it can be said, define these relationships between multiple tables. The functions that foreign keys perform include providing help data and creating dictionary objects, but the one that you will focus on will be in the data validation area. After all, maintaining data integrity is one of the main goals when defining selection screens and the most important use of foreign keys.

A foreign key field is, by definition, restricted to values that correspond to those of the primary key of the input field's check table. This is how the link between the two tables is made. One table, FORKEY1, can be thought of as the foreign key (or dependent) table mainly because it includes foreign key fields that are assigned to primary key fields in CHECK1, which is referred to as the check (or reference) table.

Some check tables can have multiple primary key fields. In such cases, assignments must be made for each field when initiating a foreign key relationship. Three options are as follows:
Use a partial foreign key. In this case, some fields will not be a factor when validating acceptable values for entries in the foreign key field. Certain fields are flagged as generic in this case and thus ignored by the system on validation.

Use a constant foreign key. In order for the field input to be valid, the value must match that of the constant in the check table.

Create a field-to-field assignment. This is the most thorough of the three choices. Every primary key field in the check table is matched with a field in the foreign key table and all key fields are then used to determine valid entries in the foreign key table.

Basically, the way a foreign key works resembles that of a direct select statement against the check table of the field with the foreign key. More specifically, when a foreign key check field is populated, the select statement that was generated by the SAP system when it defined the foreign key is sent by the program. If the table returns a value from that selection, the entry is valid. If the record is not found, the field input is invalid.

The following code shows the syntax for a system-generated select statement:
select * from table_1 where table_1-exam1 = fk_exam1
and table_1-exam2 = fk_exam2.

This bit of code shows an example of a system-generated select statement that is called when data is entered into the field with the foreign key definition. In this scenario, an entry in this screen field is permitted only if the select statement produces valid data from the check table using the data entries made in fields fk_exam1 and fk_exam2 as keys.

Cardinality is a description of the relationship between one or more data elements to one or more of another data element. If a foreign key linking two tables has been defined, the record of the foreign key table refers to a record of the check table. This reference is constructed by assigning fields of one table, the foreign key table, to the primary key fields of the other table, the check table.

The relationship exists only if the foreign key fields are of the same data type and length as the corresponding primary key fields. A check or parent table is the table that is referenced by the foreign key itself. This is usually a value table, but it can also be a table consisting of a subset of the contents of a value table. A value table dictates the valid values that are assigned to the data element's domain.

In some cases, a constant foreign key might best suit your needs. This is the case when all valid entries in the input field contain a specific value in the key field of the cited check table. Upon the select statement's query, the constant field is checked against the primary key field that contains the fixed value.

Click Here to Read More !!!!