After you complete this chapter, you will be able to:
A foreign key is a field in a table that is connected to another table via a foreign key relationship. The purpose of the foreign key relationship is to validate the data being entered into one table by checking against a valid set of values in another table. The table that contains the foreign key is called the foreign key table. The table that contains the valid set of values is called the check table (see Figure 4.1). The field that is validated and on which the foreign key relationship is created is called the foreign key.
Figure 4.1 : The foreign key table and the check table.
For example, your -lfa1 table contains country codes in a field named land1. You can create a second table, for example -t005, and fill it with a list of valid country codes. Then, if you create a foreign key like the one shown in Figure 4.1, a check will automatically be done against the check table for a valid value. With such a foreign key in place, the user cannot insert invalid country codes into table -lfa1.
A foreign key gets its name from the fact that it must always check against a field in the primary key of another table.
Foreign key checking is performed by the R/3 user interface. When you type a value into a field and press the Enter key, behind the scenes the user interface formulates a select statement to validate the foreign key field and sends it to the database. If a matching row is not found in the check table, the user sees a standard message indicating that the value he entered is invalid. If a matching row exists in the check table, the values entered on the screen are allowed to pass to the underlying ABAP/4 program. Thus, the foreign keys are already checked before the program receives the values. In addition to the Enter key, foreign keys are also checked when a function key, a pushbutton, or a menu item is selected.
Foreign keys are checked by the user interface only. They do not exist in the database, and they are not checked if you merely issue a database update statement. No referential integrity constraints are kept in the database. Therefore, an incorrectly written ABAP/4 program can violate referential integrity; it can insert invalid values into database tables. For that reason, ABAP/4 programs that need to update the database with data that comes from a source other than the user interface usually pass that data through a user interface in order to validate it.
| NOTE |
For more information on using the user interface to validate data, refer to the R/3 Library help for BDC (Batch Data Communication) programs. To view this documentation, from any screen choose the menu path Help->R/3 Library. You will see the main menu of the R/3 library. From there, click on the following tabs: Basis Components->ABAP/4 Development Workbench-> Basis Programming Interfaces->Transferring Data With Batch Input. |
To create a foreign key:
The second requirement exists to make sure that the fields being compared are compatible in data type and length (see Figure 4.2).
| NOTE |
In Figure 4.2, both fields use the same data element as well as the same domain. Notice that it is not required that they both use the same data element-only the domains must be the same. |
Because these fields share a common domain, the integrity of the
comparison between the two fields is guaranteed because their
data types and lengths will always match.
Now it is time for you to create a simple foreign key. This example will enable you to become familiar with the screens involved in this process; all of the fields in those screens will be explained in detail later in this chapter. The following procedures demonstrate how create check table ztxt005, and then a foreign key on ztxlfa1-land1 by using ztxt005 as the check table. After viewing this procedure, you will be asked to create your own -t005 table and then create a foreign key relationship from -lfa1-land1 to check table -t005.
Before you create a foreign key, you must first have a check table.
Although there is already a country code table in R/3, for practice
you will create and use your own. The check table will be named
-t005 and will contain the
fields and use the data elements shown in Table 4.1. (An x in
the PK column indicates fields that form the primary key.)
Following is the creation procedure for check table -t005. If you have trouble, refer to the troubleshooter for the transparent table creation procedure for pre-existing domains and data elements on Day 3.
Start the ScreenCam "How to Create Check Table -t005" now.
To create your check table:
Choose the menu path Utilities->Create Entries to enter data into your newly created check table. Enter six rows with land1 values of US, CA, DE, IT, JP, and AU.
Start the ScreenCam "How to Create a Foreign Key" now.
To create a foreign key:
You have just created a foreign key relationship between the -lfa1 and -t005 tables. -lfa1-land1 is the foreign key field, and -t005 is the check table. The user interface will validate the value within the -lfa1-land1 field against the values in the -t005-land1 column.
If you encounter problems, the following procedure is described in more detail in the next section. To test your foreign key:
After you have created a foreign key, the name of the check table appears in the CheckTable column on the Dictionary: Table/Structure screen. If a field is a foreign key, the CheckTable column will contain the name of the check table for that field.
Look at your table now. You should see the name of your check table in the CheckTable column.
When you created the foreign key, you did not have to specify the fields that should participate in the foreign key relationship-the system determined it automatically. This section explains how the system determines these field names.
During the creation of a foreign key, you put your cursor on the foreign key field and pressed the foreign key button, and the system generated a foreign key proposal consisting of pairs of fields. In each pair, one field comes from the check table and the other from the foreign key table. The number of pairs is equal to the number of primary key fields of the check table. All of the primary key fields of the check table must be included in the foreign key relationship.
The system searches these primary key fields for the one that has the same domain as the foreign key field, and pairs it with your foreign key field.
If there are multiple fields in the primary key of the check table, it will try to find a match for each of the remaining fields. One by one, the system will try to find a field in the foreign key table that has the same domain as the check table field. Failing that, it will try to find a field that has the same data type and length. If it finds more than one match, the system picks one and warns you that the assignment is ambiguous. The process is repeated until all primary key fields from the check table have been paired with a field from the foreign key table.
In addition to F1 help, you can also provide something called F4 help to the user. F4 help is a list of valid values that the user can enter into a field. In order to obtain F4 help, the user positions their cursor in a field and presses the F4 key. F4 help is also known as possible entries help because it is the list of possible entries allowed in the field. Both terms are used interchangeably by SAP.
When you create a foreign key, F4 help is automatically provided for that field.
Start the ScreenCam "Using a Foreign Key to Provide F4 Help" now.
On a screen, if you place your cursor within a foreign key field, a down-arrow will appear at the end of the input field. This is the F4 help. If you click the down-arrow or press the F4 key, a list of possible, valid entries is displayed. This list is the contents of the check table. In this list, the primary key columns of the check table are displayed, excluding mandt.
| NOTE |
The column heading and width in the possible entries list come from the Header field in the data element for the check table field displayed. |
Follow this procedure to test the foreign key relationship you created on -lfa1-land1. If your foreign key doesn't work, try this procedure using ztxlfa1, then compare ztxlfa1 with your table to determine the problem.
The foreign key relationship provides a mechanism for validating data entered by the user on the screen. If the field is a foreign key field, the value is compared against the check table. If the value doesn't exist in the check table, a standard error message is issued.
Batch programs that read sequential files or other sources of data other than the screen and update the database directly must validate the data. Such a program should be coded in one of three ways:
A compound foreign key is a foreign key composed of two or more fields. In other words, a check is done to compare two fields in the foreign key table against two fields in the check table. The combination of values must exist in the check table before they can be inserted into the foreign key table. However only one field on the screen will trigger the compound foreign key check.
When you create a compound foreign key, the field on which you actually define the foreign key is called the check field. Only a non-blank value in the check field triggers the check against the check table. A value in any of the other fields within the compound foreign key will not trigger the validation.
For example, the regio field in ztxlfa1 should only contain valid state or province codes. The combination of regio and land1 together must be valid. Therefore, a check table (ztxt005s) containing valid combinations of regio and land1 is needed. After creating this check table, a compound foreign key is needed in ztxlfa1 to validate the combination of regio and land1 against the check table. Incidentally, ztxt005s-land1 should also be validated against ztxt005-land1 (see Figure 4.4).
You create a compound foreign key almost exactly the same way as a foreign key containing a single field. You begin by positioning your cursor on a field, in this case ztxlfa1-regio, and then pressing the Foreign Keys button. Because your cursor is on regio, it becomes the check field of the compound foreign key. Although the foreign key is composed of multiple fields, only one of those fields will trigger a check against the database. Because regio is the check field, a value entered into it on the screen triggers a check. If the check field is non-blank when the user presses the Enter key, a check is carried out against the check table comparing all fields of the foreign key. If the check field is blank, no checking is done even if the other fields contain values.
| CAUTION |
As with the simple foreign key, the domain names of the check field and its associated field in the check table must match. However, when the foreign key is created, the rest of the domain names in the compound foreign key do not have to match; the foreign key can be created if only their data types and lengths match. Later, if the data type or length in one of these domains is changed, the fields will no longer match and the results of the foreign key check will be unpredictable. For this reason, although R/3 does not enforce that all domain names of a compound foreign key match, it is highly desirable. As a rule of thumb, when changing the data type or length of field in a compound foreign key other than the check field, you must check to see whether the foreign key and check table fields are using the same domain. If they are not, you must update them both to have the same data type and length. Failure to do so will result in unpredictable operation of the foreign key. |
If you create a foreign key relationship to a check table containing more than one field in the primary key, all of the primary key fields of the check table must be included in the foreign key. They do not all have to be checked (see the section "Generic Foreign Keys" that follows), but they all must be included.
Because most check tables contain the mandt field, it forms a part of most foreign keys (see Figures 4.5 and 4.6).
Figure 4.5 :A compound foreign key involving the mandt field.
Figure 4.6 : The definition of the foreign key shown in Figure 4.5.
By including mandt in the check table, independent and valid sets of values can be defined for each logon client and can differ between clients. This capability is highly desirable to separate the data between clients and ensure that they are completely independent of each other.
F4 help is only available on the check field of a compound foreign key. When invoking F4 help, all of the primary key fields of the check table will be displayed. The column containing the check field will be highlighted in the list. The column widths and titles come from the Header field in the data elements.
The cardinality of the foreign key relationship describes, for each value in the check table, how many rows of data are allowed to be in the foreign key table. It is entered on the Create Foreign Key screen (refer to Figure 4.3). Cardinality is described as X:Y, where X refers to the check table and Y refers to the foreign key table. X can only have the values 1 or C, and Y can be 1, C, N, or CN.
The values of X mean:
The values of Y mean:
Cardinality is not enforced by the R/3 system. Specifying cardinality is optional, and the system will not check cardinality to determine whether that update should be allowed to take place if an ABAP/4 program updates a table. The only time cardinality is used is when you create an aggregate object in the DDIC.
An aggregate object is a DDIC object composed of more than one table. An example of an aggregate object is a view.
When you create a foreign key you should specify the cardinality. If you don't specify it, you will be unable to include the table in an aggregate object.
The foreign key field type should also be specified on the same screen as the cardinality when you create the foreign key (refer to Figure 4.3). It can be one of the following values:
Choose Key Fields/Candidates if the foreign key field is one of the primary key fields of the foreign key table. Choose Non-Key Fields/Candidates if it is not. For example, assume table t1 is composed of fields f1 through f10, and its primary key fields are f1, f2, and f3. If you were to define a foreign key on field f3, Key Fields/Candidates would be the correct type because f3 is part of the primary key. If you were to define a foreign key on field f5, Non-key Fields/Candidates would be correct because f5 is not one of the primary key fields.
A key candidate is a field in a table that, by itself or in conjunction with another field that is not part of the primary key, could be used to uniquely identify a row in the table. To put it another way, if there is way to uniquely select a row from a table without using primary key fields, key candidates exist in that table. The key candidates are the fields not within the primary key that can be used to uniquely identify a row; in essence they can serve as an alternate primary key.
For example, ztxlfa1 has a single primary key field that contains a unique identifier for each row. If you assume that the combination of erdat and ertim (creation date and time) is also unique for every row, these date and time fields are key candidates. If either one appeared in a foreign key, the correct foreign key type would be key fields/candidates.
When creating a foreign key, you should choose key fields/candidates if the foreign key field is one of the primary key fields of the table or is a key candidate. Choose non-key fields/candidates if it is not.
The R/3 system supports multiple spoken languages, and thus enables users to sign on using the language of their choice. Because of this, descriptions in R/3 are stored in special language-dependent tables called text tables.
| TIP |
Users can set their own default logon language. This is done in the user profile by choosing the menu path System->User profile->User defaults. Changes to your user profile are not effective until you next log on. |
A text table is a table that contains spoken-language descriptions of values in a check table. These descriptions are stored in multiple languages. The primary key of the text table is the same as the primary key of the check table, with the addition of a spras (language) column.
For example, the ztxt005 table has country codes in it. Country names are stored in a separate table named ztxt005t (shown in Figure 4.7) because you actually need many names for one country code. Because it stores language-specific descriptions of a generalized code, ztxt005t is called a text table.
The primary key of ztxt005t contains the same fields as the primary key of ztxt005, with the addition of a spras (language) column. The spras field contains the language code and enables this table to contain a description for multiple logon languages.
The primary key of any text table is composed of the fields mandt and spras, followed by the validation field (or fields). One or more description fields follow this primary key.
A foreign key relationship is defined on ztxt005t-land1 to check table ztxt005. The foreign key field type should be key fields of a text table.
The foreign key type "key fields of a text table" indicates to the R/3 system that the foreign key table is a text table. When you choose this type, the first description that follows the primary key is displayed in the F4 help, in the logon language of the user. Therefore, this key type has two special properties:For example, text table ztxt005t contains a foreign key relationship from ztxt005t-land1 to check table ztxt005, and the type is "key fields of a text table". When you invoke F4 help on ztxt005-land1, the user sees the primary key columns of the check table ztxt005, plus the contents of the first column that follows the primary key of ztxt005t. Only the rows where spras is equal to the current logon language are displayed. The result is that the user sees descriptions in his logon language for the codes in ztxlfa1.
- When the rows of the check table are displayed in response to an F4 help request, the first description field from the text table will appear in the same list, as if it were a part of the check table.
- Only the rows from the text table having the same language code as the user's current logon language appear in the F4 help list.
The contents of tables ztxt005 and ztxt005t are shown in Tables 4.2 and 4.3.
| land1 |
| US |
| CA |
| DE |
| IT |
| JP |
| AQ |
| CC |
| Canada | ||
| Kanada | ||
| Germany | ||
| Deutschland | ||
| United States | ||
| USA | ||
| Italy | ||
| Italien | ||
| Japan | ||
| Japan | ||
| Antarctica | ||
| Antarctica | ||
| Coconut Islands | ||
| Kobinseln |
Start the ScreenCam "Text Table Demonstration: The Effect of the Logon Language" now.
Now is a good time to try creating your own text table. Use ztxt005t as a model. Your text table will be named -t005t and will contain the fields and use the data elements and domains shown in Table 4.4. You will also have to create the data element -landx. Use the existing SAP domain text15 for your new data element. An x in the PK column indicates fields that form the primary key.
After activating -t005t, enter data into it using SE16. Use the sample data shown in Table 4.3.Now create a foreign key on -t005t-land1. Follow the foreign key creation procedure previously given. Use -t005 as the check table. On the Create Foreign Key screen, specify a foreign key field type of Key fields of a text table. You might want to review the screencam "How to Create a Foreign Key" before beginning.
After creating your foreign key, follow the procedure for testing the foreign key relationship on -lfa1-land1. In step 11, notice that the description from ztxt005t is also displayed. Also, log on again, this time specifying a logon language of D (German), and repeat the test. This time you should see the German descriptions in step 11.
Recall that when you create a foreign key, all of the primary key fields of the check table must be included in the foreign key relationship. However at times, you may not want to perform a check against all of these fields. In other situations, you may wish to check against a constant value. In either of these cases, you can define either a generic or constant foreign key.
A generic foreign key is a foreign key in which one of the primary key fields of the check table fields is marked as generic. When a primary key field is marked as generic, it doesn't have a counterpart in the foreign key table, and it does not participate in the check.
For example, within the Materials Management application, the mara table is the Material Master table. It contains the master list of materials used for manufacture and the attributes of each material.
The setup program for this book created a ztxmara table similar to mara. The fields of ztxmara are shown in Figure 4.8.
Figure 4.8 : Table ztxmara is similar to the R/3 Material Master table mara.
The ztxmara-stoff field contains a hazardous material number. If the field is non-blank, the material requires special handling; the stoff number indicates the type of handling required. The handling numbers are defined in table ztxmgef, which is illustrated in Figure 4.9. In our example, assume ztxmgef contains a row with stoff equal 1. That row indicates a handling procedure that requires gloves. Updating a material and placing a 1 in the ztxmara-stoff field for the material indicates that the material requires special handling with gloves.
Figure 4.9 :The ztxmara and ztxmgef tables relate via the stoff field.
The check table for ztxmara-stoff is ztxmgef. The foreign key definition is shown in Figure 4.10.
This foreign key validates the values entered into ztxmara-stoff and ensures that only valid handling numbers exist in the ztxmara table. Unfortunately, handling regulations can vary with geographical regions. Therefore, the primary key of ztxmgef is composed of stoff, regio, and land1. However, ztxmara doesn't contain any geographical information - that information is contained in plant tables.
Remember, a foreign key must include all primary key fields from the check table. Therefore, regio and land1 from ztxmgef appear in the foreign key definition. However, for the purposes of ztxmara, validating ztxmara-stoff against ztxmgef-stoff is good enough; location information doesn't exist in ztxmara and doesn't matter for this validation. It is enough to know that the specified special handling number exists.
In this foreign key relationship, the regio and land1 fields in the primary key of ztxmgef are be ignored. To cause these fields to be ignored during validation, they are defined in the foreign key relationship as generic. The tickmark in the Generic check box on the Create Foreign Key screen accomplishes this.
When this foreign key is checked, only the combination of mandt and stoff must exist in the check table. The regio and land1 fields are ignored.
Constant foreign keys are compound foreign keys where one of the check table field names is replaced by a constant value. This constant value is entered on the Create Foreign Key screen (see Figure 4.11).
Figure 4.11: The country field as a constant foreign key.
For example, assume you need to create a new vendor table ztxlfa1us like ztxlfa1 containing U.S. vendors only, but for compatibility reasons, you want it to have exactly the same structure as ztxlfa1. The country code in this table would always be US. You could create a constant foreign key to restrict the values in table ztxlfa1us. An example of the definition is shown in Figure 4.11.
Foreign key fields of a compound foreign key do not all have to reside in the same table. If they do not, this is known as an adapted foreign key. For example, assume that the country code for the vendor is not stored at all in ztxlfa1, but instead in ztxlfa1cc. When you create the foreign key on the region field, you would change the check table field for land1 to ztxlfa1cc-land1 (see Figure 4.12). The validation on the regio field would check to see whether the combination of mandt and regio existed in ztxt005s and whether land1 existed in any row of ztxt005cc.
Figure 4.12: An example of an adapted foreign key.
Within the domain is the Value Table field. The table named within this field provides the following functions to the domain:
Whenever you create a foreign key relationship, the system looks in the value table field. If there is a table name there, it proposes that name as the check table.
Some readers will have difficulty with this concept, so I will explain it in depth in the following section.
In order to understand the purpose of the Value Table field, you should be familiar with the "bigger picture" of database design and development. I will begin by describing this bigger picture.
Before you create any tables in the DDIC, you usually do some database design. This design describes the tables that will be created, their relationships, and the type of data that each will contain. It will usually designate certain tables to be check tables for validating the data within other tables. For example, a country code check table may be needed to validate country codes for all of the tables where country codes will be stored. When you create a set of tables within R/3, you will usually create the check tables first.
When you create a check table, it exists for one primary purpose: to validate data. You can create multiple foreign key relationships linking many other tables to a single check table. The Value Table field in the domain exists to simplify the task of creating these relationships.
Before I continue, I want you to imagine that the Value Table field within the domain has a completely different name. Wipe the term "Value Table" from your mind, and imagine that field is called the "Default Check Table" field.
To simplify the example, our check table will have a single primary key field, illustrated in Figure 4.13. To illustrate this concept, I will describe the process you would go through to create this check table and use it in a foreign key relationship.
Figure 4.13: The Value Table field within the domain contains the name of a check table.
When you create a check table, you must first create a domain. You would always create a new domain specifically for a check table. You would then create the data element, and then the table itself. You would then activate the table. You would then go back into the domain for the primary key field and put the name of the check table you just created in the Value Table field - but remember we call it the Default Check Table field.
Now, you would create another table, in our example it is ztxlfa1. You would create the land1 field and use the ztxland1 data element, and then both fields would use the same domain.
Now you would create the foreign key to validate land1. You would place your cursor on the ztxlfa1-land1 field and press the Foreign Key button. When you do this, the system will look in the domain at the Value Table field (remember we call it the Default Check Table field). If there were a table name there, the system would automatically propose that name as the name of the check table. In our case, the system would find ztxt005. Therefore, the system would propose ztxt005 as the check table-exactly what we would want. The foreign key proposal would be shown, and we could then save it.
In this example, the system automatically created the foreign key for us, because we put the name of the check table in the Value Table field. Using three mouse clicks, we created a foreign key! That, in essence, is the primary reason for the Value Table field. It exists to make the creation of foreign keys easier.
To summarize, the Value Table field is used in two ways by the system:
In this section you will add a value table to a domain and observe its effect on the creation of a foreign key.
Edit domain -land1 now and enter -t005 in the Value Table field, then activate the domain.
Now you will delete the foreign key on the -lfa1-land1 field and then create it again so that you can see the effect of the Value Table field on the foreign key creation process. To do so, follow the procedure below.
With a table name in the Value Table field in the domain you can quickly and reliably create foreign keys.
The CheckTable column on the Dictionary: Table/Structure screen performs two functions:
There is an exception to the second point above. If you are currently displaying a value table, the asterisk will not appear in the field whose domain references the value table you are viewing.
If a field contains a value table but is not a foreign key, when that field appears on a screen no validation is done on the field. The value table does not perform validation. Only a foreign key validates values.
With only a value table, a down-arrow will not appear at the end of the field as it does for a foreign key field. However, if you place your cursor in the field and press F4, the F4 key will still display a list of values from the value table. There is no indication on the screen that F4 functionality is available, and no checking is done if a value is entered in the field.
This functionality could be useful when you want to provide the user with a list of suggested values but want to allow other values to be typed into the field as well.
Two types of table fields need special treatment:
Assume you go to the bank and ask for 1000. The teller would probably ask you "1000 what?". You might reply "1000 dollars." Or you might be even more specific and ask for "1000 U.S. dollars." Monetary amounts in R/3 are stored in two fields: one to hold the actual numeric amount (1000) and one to hold the currency (USD). The numeric amount field is called the currency field and the other field is called the currency key field.
| TIP |
What many people refer to as currency is actually a currency code (USD for U.S. dollar, CAD for Canadian dollar, and so on). SAP uses the word "key" as a synonym for "code," so it calls the field containing the currency code the "currency key." This applies to most code fields in R/3; the country code is called the country key, the region code is the region key, and so on. |
Currency fields have these requirements:
The currency key is known as the reference field. It is another field in the same or another table. It must have the type CUKY (currency key) in the domain. It indicates the currency key for the currency field that it references.
For example, assume you create a table containing a list of payments made to vendors. You would need a payment amount field (field name wrbtr) and a currency key field (usually waers) to completely indicate the amount and currency key used for that payment. To link the two fields together, you would double-click on the currency field name in the table and then enter the currency key table and field name in the fields Reference Table and Reference Field (see Figure 4.14).
Figure 4.14: The reference fields on the Display Field screen.
A quantity field is a field that contains a numeric measurement. For example, such a field might contain a measure of weight, length, temperature, or electricity. To be meaningful, a unit of measure such as pounds, inches, Fahrenheit, or kilovolts must accompany it. Quantity fields have these requirements:
The UNIT field is the reference field for the QUAN field. The UNIT field can be in the same table or in another table. The UNIT field contains the measurement unit for the measurement in the quantity field.
For example, in table ztxmara, the ntgew field contains the net weight of a material and the gewei field contains the units, such as pounds or kilograms (see Figure 4.15). The ntgew field has a data type of QUAN and the data type of gewei is UNIT. If you double-click on ntgew, you will see that the reference table is ztxmara and the reference field is gewei (see Figure 4.16).
Figure 4.15: This is the structure of the ztxmara table showing the ntgew and gewei fields.
In addition to tables, structures can also be defined in the Data Dictionary. As you might expect, a structure is a series of fields grouped together under a common name. It is very similar to a table. Like a table, it can be used within a program on the tables statement to define a work area.
The differences between a structure and a table are as follows:
A structure doesn't have an associated database table.
Structures follow the same naming conventions as transparent tables, and you cannot have a table and structure of the same name.
You would create a structure in the DDIC if you wanted to define the same work area in multiple programs. For example, if you wanted to write records to a sequential file using one ABAP/4 program and then read them in using another, both programs need to know the layout of those records. You would create a structure in the DDIC that defines the record layout, and then name that structure on the tables statement in both programs. This would create an identical work area in both programs.
The procedure for creating a structure is almost the same as for creating a transparent table. (Please refer to the procedures for creating a transparent table.) The only differences are the following:
A structure can contain another structure. In other words, you can nest structures one within another. This can be used to reduce maintenance by grouping fields together into a structure and then including that structure within another structure, or even within a table.
For example, a person's address is composed of a set of fields such as street, city, region, country, and postal code. You might need to keep such an address in multiple tables. Within the vendor table you might want to keep the vendor's address, in the customer master the customer's address, and in the employee table the employee's address. If you create a structure to group the fields that form the address together, you could then include that structure into the table definitions. When the table is activated, the fields of the structure are added to and exist in the database table as if they were defined within it. They will have the same name as the name in the structure. To include a structure within a table, (or within another structure), type .INCLUDE in the field name column, and enter the structure name in the data element column.
In Figure 4.17, the table ztxempl (employee table) includes structure ztxaddr (see Figure 4.18), which consists of address fields stras (street), ort01 (city), regio, and land1. Table ztxempl therefore contains these fields: ztxempl-stras, ztxempl-ort01, ztxempl-regio, and ztxempl-land1.
Figure 4.18: The structure ztxaddr contains the address fields that are included in table ztxempl.
To view the expanded includes within the definition of the table itself, choose the menu path Extras->Substructures->Expand All Substr.. All the field names from an included structure will appear below the .INCLUDE, as shown in Figure 4.19.
The chain of structures created by including one structure within another is called an include chain. The maximum nesting depth is nine, and only one table can be included in an include chain. In other words, you cannot include a tabl
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}