After you complete this chapter, you should be able to:
There are many versions-also called release levels-of the R/3 system in use today. Release 3.0 was the first version, but since its introduction, SAP has also released versions 3.0a through 3.0f, 3.1g, 3.1h, and 4.0a through 4.0c. You can determine the release level of your system using the menu path System->Status.
This book was tested on a 3.0f system. Your system may be on another release level. Although most of the differences should be minor with regard to the topics covered here, some differences may cause confusion or cause the information in this book to appear incorrect. For example, menu paths can change between release levels. Wherever possible, differences that may cause confusion have been noted in this text. However, if the functionality in your system appears to differ from that described here, you can consult the R/3 release notes, available online, to determine if the difference can be attributed to the release level. To access the release notes, use the following procedure:
Start the ScreenCam "How to Display R/3 Release Notes" now.
To display the R/3 release notes:
As a review, please take a few minutes and re-read the section in Day 2 titled "Introducing the R/3 Data Dictionary" at this time.
Data Dictionary objects are used in most ABAP/4 programs. The interlocking nature of ABAP/4 programs and DDIC objects makes in-depth knowledge of the R/3 Data Dictionary an essential programming skill. Therefore, beginning with this chapter, you will learn how to create DDIC objects such as tables, data elements, and domains.
| NOTE |
Many development objects used as examples throughout this book (such as tables, domains, and data elements) are based on actual development objects in the R/3 system. The example objects will have the same name as the actual R/3 objects, but they will be prefixed with ztx. For example, lfa1 is a real table in R/3, and the example table in this book is ztxlfa1. |
In R/3 there are three table types: transparent tables, pooled tables, and cluster tables. They are shown in Figure 3.1.
Figure 3.1 : The three table types in the R/3 Data Dictionary.
A transparent table in the dictionary has a one-to-one relationship with a table in the database. Its structure in R/3 Data Dictionary corresponds to a single database table. For each transparent table definition in the dictionary, there is one associated table in the database. The database table has the same name, the same number of fields, and the fields have the same names as the R/3 table definition. When looking at the definition of an R/3 transparent table, it might seem like you are looking at the database table itself.
Transparent tables are much more common than pooled or cluster tables. They are used to hold application data. Application data is the master data or transaction data used by an application. An example of master data is the table of vendors (called vendor master data), or the table of customers (called customer master data). An example of transaction data is the orders placed by the customers, or the orders sent to the vendors.
Transparent tables are probably the only type of table you will ever create. Pooled and cluster tables are not usually used to hold application data but instead hold system data, such as system configuration information, or historical and statistical data.
Both pooled and cluster tables have many-to-one relationships with database tables. Both can appear as many tables in R/3, but they are stored as a single table in the database. The database table has a different name, different number of fields, and different field names than the R/3 table. The difference between the two types lies in the characteristics of the data they hold, and will be explained in the following sections.
A pooled table in R/3 has a many-to-one relationship with a table in the database (see Figures 3.1 and 3.2). For one table in the database, there are many tables in the R/3 Data Dictionary. The table in the database has a different name than the tables in the DDIC, it has a different number of fields, and the fields have different names as well. Pooled tables are an SAP proprietary construct.
When you look at a pooled table in R/3, you see a description of a table. However, in the database, it is stored along with other pooled tables in a single table called a table pool. A table pool is a database table with a special structure that enables the data of many R/3 tables to be stored within it. It can only hold pooled tables.
R/3 uses table pools to hold a large number (tens to thousands) of very small tables (about 10 to 100 rows each). Table pools reduce the amount of database resources needed when many small tables have to be open at the same time. SAP uses them for system data. You might create a table pool if you need to create hundreds of small tables that each hold only a few rows of data. To implement these small tables as pooled tables, you first create the definition of a table pool in R/3 to hold them all. When activated, an associated single table (the table pool) will be created in the database. You can then define pooled tables within R/3 and assign them all to your table pool (see Figure 3.2).
Figure 3.2 : Pooled tables have a many-to-one relationship with table pools.
Pooled tables are primarily used by SAP to hold customizing data.
When a corporation installs any large system, the system is usually customized in some way to meet the unique needs of the corporation. In R/3, such customization is done via customizing tables. Customizing tables contain codes, field validations, number ranges, and parameters that change the way the R/3 applications behave.
Some examples of data contained in customizing tables are country codes, region (state or province) codes, reconciliation account numbers, exchange rates, depreciation methods, and pricing conditions. Even screen flows, field validations, and individual field attributes are sometimes table-driven via settings in customizing tables.
During the initial implementation of the system the data in the customizing tables is set up by a functional analyst. He or she will usually have experience relating to the business area being implemented and extensive training in the configuration of an R/3 system.
A cluster table is similar to a pooled table. It has a many-to-one relationship with a table in the database. Many cluster tables are stored in a single table in the database called a table cluster.
A table cluster is similar to a table pool. It holds many tables within it. The tables it holds are all cluster tables.
Like pooled tables, cluster tables are another proprietary SAP construct. They are used to hold data from a few (approximately 2 to 10) very large tables. They would be used when these tables have a part of their primary keys in common, and if the data in these tables are all accessed simultaneously. The data is stored logically as shown in Figure 3.3.
Table clusters contain fewer tables than table pools and, unlike table pools, the primary key of each table within the table cluster begins with the same field or fields. Rows from the cluster tables are combined into a single row in the table cluster. The rows are combined based on the part of the primary key they have in common. Thus, when a row is read from any one of the tables in the cluster, all related rows in all cluster tables are also retrieved, but only a single I/O is needed.
A cluster is advantageous in the case where data is accessed from multiple tables simultaneously and those tables have at least one of their primary key fields in common. Cluster tables reduce the number of database reads and thereby improve performance.
For example, as shown in Figure 3.4, the first four primary key fields in cdhdr and cdpos are identical. They become the primary key for the table cluster with the addition of a standard system field pageno to ensure that each row is unique.
As another example, assume the data from order header and order item tables is always needed at the same time and both have a primary key that begins with the order number. Both the header and items could be stored in a single cluster table because the first field of their primary keys is the same. When implemented as a cluster, if a header row is read, all item rows for it are also read because they are all stored in a single row in the table cluster. If a single item is read, the header and all items will also be read because they are stored in a single row.
Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. On a pooled or cluster table:
| CAUTION |
The use of pooled and cluster tables can prevent your company from using third-party reporting tools to their fullest extent if they directly read data-base tables because pooled and cluster tables have an SAP proprietary for-mat. If your company wants to use such third-party tools, you may want to seek alternatives before creating pooled or cluster tables. |
Because of these restrictions on pooled and cluster tables and because of their limited usefulness, this book concentrates on the creation and use of transparent tables. The creation of pooled and cluster tables is not covered.
You now know what transparent tables are, and the differences between transparent, pooled, and cluster tables. You will now learn the components that are needed to create tables.
A table is composed of fields. To create a field you need a data
element. The data element contains the field labels and online
documentation (also called F1 help) for the field. It is
purely descriptive; it contains the semantic characteristics for
the field, also known as the "business context." The
labels you provide within a data element will be displayed on
the screen beside an input field. The data element also contains
documentation that is displayed when the user asks for help on
that field by pressing the
F1 key.
A data element's definition requires a domain (see Figure 3.5). The domain contains the technical characteristics of a field, such as the field length and data type.
Domains and data elements are reusable. A domain can be used in more than one data element, and a data element can be used in more than one field and in more than one table.
For example, assume you need to design a customer information table called zcust that must contain work, fax, and home telephone numbers (see Figure 3.6).
Figure 3.6 : A design example using tables, data elements, and domains.
To create a field, you usually start by creating a domain for it. In this case, you might create a generic telephone number domain, name it zphone and give it a data type of CHAR and a length of 12. This would be a generic telephone number domain; most types of telephone numbers could be stored using this domain. As such, it can be used to define specific types of telephone numbers, such as fax or home telephone numbers.
After creating the domain to hold the purely technical description of a field, you then create a data element to hold the descriptive attributes of the field. In the data element you must enter the name of a domain to give it technical characteristics. Then, you enter the labels and documentation (F1 help) to describe the data you will store. In this example, you would probably create three data elements, one for each of the home, work, and fax telephone numbers. In each data element, you would enter field labels describing the type of telephone number you will store with it, and the F1 help for the end-user.
Having created the data elements, you can now create the table. You could create three phone number fields in the table (home, work, and fax) and assign the corresponding data element to each field. A data element is assigned to each field. This gives the field descriptive information from the data element and technical information from the domain that it references. When the field is used on a screen, it obtains a label and F1 help documentation from the data element, and its length and data type form the domain within the data element.
In another example, you might need to store a person's name in three different tables: customer, vendor, and employee tables. In the customer table you want to store a customer name, in the vendor table a vendor name, and in the employee table an employee name. Because it is a good idea to give the same data type and length to all person-name fields, you can create a single generic person-name domain, for example zpersname. Then you can create a data element for each business usage of a person's name: for the customer name, the vendor name, and the employee name. Within each data element you refer to your zpersname domain to give them all the same characteristics. You could then use these data elements to create fields within each table.
If you need to change the length of the field after you have created a table, you only need to change it in the domain. If the domain is used in more than one table, the change is automatically propagated to all fields that use that domain.
For example, if the business analysts requested that you increase the length of your person name field from 12 to 15 characters, you would change the length in the zpersname domain. When you activate your change, the lengths of all name fields based upon this domain (in the customer, vendor, and employee tables) will also change.
Each R/3 system comes with more than 13,000 preexisting domains created by SAP. When you create a new field, you must decide whether to create a new domain or reuse an existing one. To make this decision, determine whether the data type or length of your field should be dependent on an existing SAP field. If your field should be independent, create a new domain. If your field should be dependent, reuse an existing SAP domain. Similarly, you should reuse data elements if your field labels and documentation should change when SAP changes theirs.
For example, assume you wish to create a new table to contain additional vendor information. When you design the table, you must associate the vendors in your table to those in the SAP table.
In your table, create a primary key containing the vendor number. Use the existing data element to create your field. Both tables are now keyed on the SAP vendor number field using the same data elements and domains. If SAP changes the data type or length of their field, yours will change automatically.
Tables, data elements, and domains created at the customer site
must follow SAP naming conventions for customer objects. These
are outlined in Table 3.1.
| Table | ||
| Data element | ||
| Domain | ||
| Field |
All names are a maximum of 10 characters long.
The names of all tables, domains, and data elements you create must start with the character y or z. You cannot use any other character at the beginning; all others are reserved by SAP. The R/3 system enforces this convention; you will get an error message if you try to create an object having a name that doesn't conform to these conventions.
Field names can begin with any character. However, certain words are reserved and cannot be used as field names. The DDIC table trese contains the complete list of reserved words. The contents of trese can be displayed using the Day 2 procedure in the section titled "Displaying Data in the Table."
In the following sections, you will create domains, data elements, and finally, your first transparent table-it will be a scaled-down version of the SAP-supplied vendor master table named lfa1.
| NOTE |
For the purposes of this book, please assume that the R/3 system doesn't already store any vendor master information. Assume that table lfa1 does not exist, nor do its data elements or its domains. Therefore, in these exercises we will create them. |
To store vendor master information you will create table -lfa1.
It will contain fields for a vendor number, a name, a region code,
and a country code. The field names and technical characteristics
you will use are shown in Table 3.2. An x in the PK column indicates
fields that form the primary key. (The install procedure created
a table named ztxlfa1 in your R/3 system. It is very
similar to the -lfa1 table.
Use it as a reference while reading this chapter.)
These field names and their technical characteristics are based on actual fields of table lfa1.
| NOTE |
Don't change the names shown above. The exercises later in this book rely on these field names as shown. If you don't use these exact names, subsequent exercises may not work. |
Since this table contains application data, it should be client-dependent. Therefore, the first field must be mandt. (See Chapter 1 if you need to review client dependent tables.)
There are two approaches you can use when creating tables:
In the bottom-up approach, you create the domains first, then the data elements, and then the table.
In the top-down approach, you create the table first, and then create the data elements and domains as you go along.
The bottom-up approach is more intuitive for the first-time student, but it quickly becomes cumbersome. The top-down approach is much easier to use after you become somewhat familiar with the table creation process. For these reasons, I will demonstrate both techniques, starting with bottom-up.
As you read the following sections you will first learn about an object-such as a domain-and then you will create one. The objects you will create are described in Table 3.2.
| CAUTION |
Remember, when creating any of the objects in this book, use your handle (···) as the first three characters of the object name. (The characters ··· represent your handle. The handle was described in Chapter 2in the section titled "Introducing Program Naming Conventions.") Do not use ztx as the first three characters. If you use ztx, it will be very difficult to determine which objects are yours. |
Before learning about DDIC objects in depth, you should know about object activation. Activation applies to all dictionary objects.
After creating a Data Dictionary object, you will activate it. Activating an object is simple-you will simply press the Activate button. This changes the status of the object to Active.
An object must be Active before it can be used. For example, if you try to use an inactive data element when creating a field, you will get a message saying that the data element does not exist or is not active. Your response would be to activate the data element.
If you change an object, you must activate it again for the changes to take effect. If you save the changes but do not activate it, the objects that refer to it will not "know about" the change.
Before actually creating a domain, I will describe the screen you will use to create it.
In Figure 3.7 is the screen you will use to create a domain-the Dictionary: Maintain Domain screen. On this screen you specify short text, the data type, a field length, and optionally an output length. These items are explained in the following sections.
Figure 3.7 : The Dictionary: Maintain Domain screen is used to create a domain.
The Short Text field will contain a description of the domain. The end user never sees it; it is only displayed to developers. You will see it when you bring up a list of domains, such as when you search for one.
| NOTE |
Adding the word "domain" to the end of the short text description is redundant and should be avoided. For example, the short text "Generic telephone number domain" should be avoided. Instead, type "Generic telephone number." |
In this field, you will describe the type of data the domain is intended to contain. For example, the description of a reusable telephone number domain might read "Generic telephone number" or "General telephone number."
The Data Type field specifies the representation used internally by the database to store the value for that field. For some data types, it also determines the input format validation and output format of the field. For example, fields of data type DATS (date) and TIMS (time) are automatically formatted with separators when output to a list or displayed onscreen. On input, they must also be in date or time format, or an error message is issued to the user.
The most commonly used data types are listed in Table 3.3.
| CHAR | Character strings (maximum 255 characters) |
| DEC | Decimal values (maximum length 31) |
| DATS | Date field |
| TIMS | Time field |
| INT1, INT2, INT4 | Integer values |
| NUMC | Character field that can contain only numerics |
| TIP |
You should always press the Enter key after you fill in the data type field. Pressing Enter causes the screen to change based on the data type you specified. If the data type is a signed numeric type, a Sign check box will appear. For fields that allow decimals, a Decimal Places field will appear. For character fields, a Lowercase Letters check box will appear. |
The Output Length field indicates the number of bytes needed to output the field to a list or a screen, including commas, decimal point, sign, and any other formatting characters. For example, on output, date and time fields are automatically formatted with separators. Internally, a date is stored as eight characters (always YYYYMMDD), but the output length in the domain should be specified as 10 to enable two separators to be inserted. If the Output Length field is left blank, its value is automatically calculated by the system when you press Enter.
For decimal fields, you can specify the number of decimal places in the Decimal Places field.
Character fields are usually converted to uppercase before they are stored in the database. You can turn this conversion off by tickmarking the Lowercase Letters check box.
Most developers do not have problems understanding the internal representation of character or integer fields. However, the location of the decimal point in decimal fields is often a point of confusion, so it is described here.
For type DEC fields, the decimal point is not stored in the database. Only the numeric portion is stored, not the decimal. On output, the position of the decimal is determined by the value you put in the Decimal Places field of the domain.
In order for the field to be properly displayed, you must specify an output length that includes one byte for the decimal point and one byte for each thousands separator that can be displayed. However, the system will calculate the output length for you if you simply blank out the Output Length field and press Enter.
In this section, you will learn the bottom-up approach to creating a domain.
Start the ScreenCam "How to Create a Domain" now.
Perform this procedure twice to create the -lifnr and -name1 domains. Help with common problems is given in the Troubleshooter that follows it. If you have trouble with any one of the steps, don't forget to consult the Troubleshooter.
| Can't create domain | When you press the Create button, nothing happens. | Look at the status bar in the bottom of the window and press the button again. It is likely that you will see a message there. |
| When you press the Create button, you see the message "System change option does not allow changes to SAP objects." | Change the domain name to start with y or z. | |
| When you press the Create button, you see the message "Enter access key." | Change the domain name to start with y or z. | |
| When you press the Create button, you see the message "You are not authorized to make changes." | Request development authorization from your security administrator. | |
| When you press the Create button, you see the message "already exists." | The name you entered already exists in the Data Dictionary. Choose a different domain name. | |
| Getting message | "W: (calculated output length is smaller than specified)." | Blank out the Output Length field and press Enter and then Activate. |
| "E: Value table does not exist." | Blank out the Value Table field and press Enter and then activate. |
There are many places to obtain SAP documentation on the features of domains.
If you wish to see documentation describing all data types and their uses, put your cursor on the Data Type field and press F1. You will see a dialog box containing highlighted fields. Click on these highlighted fields for more details.
You can also consult the R/3 library help for additional documentation on data types and other properties of the domain. 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->ABAP/4 Dictionary->New Developments In The ABAP/4 Dictionary In Release 3.0.
For still more documentation on the data types in the domain, from within the domain choose the menu path Help->Extended help. Then click on Creating Domains, and then click on External Data Type.
To obtain documentation that describes the mapping of domain data types to ABAP/4 data types, display F1 help for the "tables" keyword. (To do so, within the ABAP/4 editor, put your cursor on the word tables and press F1.)
Before actually creating a data element, I will describe the screen you will use to create it.
Figure 3.8 shows the screen used to create a data element. Here you specify the short text, domain name, labels, and a header, which are explained in the following sections. Documentation can also be created after the data element has been saved.
Figure 3.8 : The Dictionary: Change Data Element screen.
The Short Text field describes a business context for a domain. For example, a "customer telephone number" is a specific business context for a "generic telephone number" domain, so it would be an appropriate description for a data element. The end user will see this description if they request F1 help for a field that was created using this data element.
At the bottom of the screen shown in Figure 3.8 are four text fields. The first three are field labels. When any field appears on a screen (such as an input field on an input screen), one of the short, medium, or long fields will appear to the left of it as a field label. The programmer chooses one of these field labels when he creates a screen. The contents of the Header field will appear as a column header at the top of lists.
If the fields that you create with this data element will not appear on any screens, uncheck the Maintain Field Labels check box and press the Enter key. You will no longer see the Field Label and Header fields. You will have to press Enter twice to cause the fields to disappear if these fields contain values.
After you save the data element, a Documentation button appears on the Application toolbar so that you can store free-form text. The user sees this text when he requests F1 help. In other words, when a table field that uses this data element is displayed on a screen, the user can place his cursor into that field and press F1 to display the documentation you entered here.
When you see the Documentation screen, the first line will contain the characters &DEFINITION&. This is a heading; do not change this line. Type your documentation beginning on line two.
| TIP |
Data element documentation is often very useful to the programmer. By reading this F1 help, the programmer can determine the business usage of the data. Therefore, you should always create F1 help for the user via the Documentation button. |
In this section, you learn the bottom-up approach to creating a data element.
Start the ScreenCam "How to Create a Data Element" now.
Perform this procedure twice to create the -lifnr and -name1 data elements. Help with common problems is given in the Troubleshooter that follows it. If you have trouble with any one of the steps, don't forget to consult the Troubleshooter.
| Can't create data element | When you press the Create button, nothing happens. | Look at the status bar in the bottom of the window and press the button again. It is likely that you will see a message there. |
| When you press the Create button, you see the message "System change option does not allow changes to SAP objects." | Change the data element name to start with y or z. | |
| When you press the Create button, you see the message "Enter access key." | Change the data element name to start with y or z. | |
| When you press the Create button, you see the message "You are not authorized to make changes." | Request development authorization from your security administrator. | |
| When you press the Create button, you see the message "already exists." | The name you entered already exists in the Data Dictionary. Choose a different domain name. | |
| Can't activate data element | Seeing message "No active domain exists with name." | Go to the Dictionary: Change Data Element screen and double-click on the domain name. |
| Either the domain name you entered on the previous screen does not exist or is not active. | You will then see either a dialog box or the Dictionary: Display Domain screen. | |
| If you see a dialog box with the title Create Domain, the domain does not exist. Check the name carefully. Did you enter the wrong name? It might be a good idea to open a new session and display the objects you created so far using the Object Browser. (In Day 2, see the section "Finding Your Development Objects.") | ||
| If, after double-clicking, you see the Dictionary: Display Domain screen, look at the Status field on that screen. Is the status New? If so, the domain needs to be activated. Press the Activate button and then press the Back button to return to the data element and try again to activate it. | ||
| Getting message | "Maintain field label." | Enter short, medium, and long field labels and then activate. |
| "W: Length was increased to the actual text length." | The header text you entered was longer than the field length. | |
| This is not a serious error. To bypass it, just press Enter and then activate. | ||
| Can't enter field labels. | Input fields are missing from the screen. | Tickmark the Maintain Field Labels check box and press Enter. |
Figure 3.9 shows the screen used to create a transparent table. Here you specify the short text, delivery class, field names, a data element name for each field, and select the primary key fields. The following sections explain these items in more detail.
The Short Text field is used for the same purposes as the domain Short Text fields. The end user will not see this description anywhere, but the developer will see it when bringing up a list of tables.
The value in the Delivery Class field identifies the "owner" of the data in this table. The owner is responsible for maintaining the table contents. In customer tables, you always enter an A here, which indicates that the table contains application data owned by the customer only. Other values entered in the field are useful only to SAP, and indicate that either SAP owns the data or both SAP and the customer jointly own the data.
| TIP |
For a complete list of valid values and their meanings, put your cursor on the Delivery Class field and press F1. |
Tickmarking the Tab.Maint.Allowed check box causes the menu path Utilities->Create Entries to be enabled. After activating the table and choosing this menu path, the Table Insert screen is displayed, enabling you to enter data into your table. It is useful for testing and for manual entry of small amounts of data. If the Tab.Maint.Allowed check box is blank, the menu path Utilities->Create Entries will be grayed out.
In the lower half of the screen you can enter field names in the Field Name column. The primary key fields must appear first in this list and must be indicated by a tickmark in the Key column. A data element name must be entered to the right of each field name. After filling in the field names, press the Next page button on the Standard toolbar if you want to enter additional fields.
In this section, you learn the bottom-up approach to creating a transparent table.
Start the ScreenCam "How to Create a Transparent Table Using Preexisting Domains and Data Elements" now.
Perform this procedure to create the -lfa1 table. In this procedure, we will create the table, but will only include the first three fields (mandt, -lifnr and -name1) in it. Later on, we will add the remaining fields using the top-down approach.
Help with common problems is given in the Troubleshooter that follows this procedure. If you have trouble with any one of the steps, don't forget to consult the Troubleshooter.
| Can't create table | When you press the Create button, nothing happens. | Look at the status bar in the bottom of the window and press the button again. It is likely that you will see a message there. |
| When you press the Create button, you see the message "Enter access key." | Change the table name to start with y oz. | |
| When you press the Create button, you see the message "System change option does not allow changes to SAP objects." | Change the table name to start with y or z. | |
| When you press the Create button, you see the message "You are not authorized to make changes." | Request development authorization from your security administrator. | |
| When you press the Create button, you see the message "already exists." | The name you entered already exists in the Data Dictionary. Choose a different domain name. | |
| Can't activate table | Seeing message "E-Field (Data element or domain is not active or does not exist)." | Go back one screen to the Dictionary: Table/Structure: Change Fields screen. Double-click on the data element name. You will see either a dialog box or the data element itself. |
| If you see a dialog box with the title Create Data Element, the data element does not exist. Check the name carefully. Did you enter the wrong name? It might be a good idea to open a new session and display the objects you have created so far using the Object Browser. (In Day 2, see the section "Finding Your Development Objects.") | ||
| If you can display the data element, look at the Status field. Is the status New? If not, the data element needs to be activated. Press the Activate button and then press the Back button to return to the table. | ||
| Seeing screen ABAP/4 Dictionary: Maintain Technical Settings | The technical attributes were either not entered or not saved. Enter the technical attributes now, press the Save button, and then press Back. | |
| Messages displayed in red | "E- Field (Data element or domain is not active or does not exist)." | See Can't activate table, above. |
| "E- Entry in table TAORA missing." | Look further down for a message (in red) about the Data Class or Size category. | |
| "E- Error in code generation for creating table in the DB" "E- Table (Statements could not be generated)." | Look further down for a message (in red) about the Data Class or Size category. | |
| Look further down for a message (in red) about the Data Class or Size category. | ||
| "E- Field Size category (Value not permitted)." | You entered an invalid value in the Size Category field of the technical settings. Press Back and then press Technical Settings, and change the Size Category to 0 (zero). | |
| "E- Field Data class (Value not permitted)." | You entered an invalid value in the Data Class field of the technical settings. Press Back and then press Technical settings, and change the Data Class to APPL0 (use a zero at the end of APPL). | |
| "E- Key is already defined; field cannot be in the key." | The primary key fields are not adjacent to each other. Press Back and make sure your primary key fields are all at the beginning of the table with no intervening non-key fields. (All of the tickmarks in the Key column must be together at the beginning of the table.) | |
| Seeing dialog box titled Adjust Table with the text Table must be adjusted in the database. | Table needs to be converted. | You changed the table and now a table conversion must be done to complete the activation. Choose a processing type of Online and press the Adjust button. |
| Seeing message at bottom of screen "Initial value not permitted as the field name" or: can't scroll up or: can't see fields you entered. | You tried to remove a field by blanking it out. You can't do that; you must delete fields using the Cut button on Application toolbar. Press Cut until you see the message "Selected entries were copied to the clipboard" at the bottom of the window in the status bar. | |
| Can't get past a message | A message beginning with the characters "W:" appears in the status bar and you can't get any further. | Press the Enter key in response to the message. |
In this section you will learn to add fields to a table using the top-down approach. You will add the remaining two fields (-regio and -land1) to your -lfa1 table.
Using the top-down approach, you can add fields to a table before you create the data elements and domains. You can simply create data elements and domains as you go along.
To do so, you will enter a data element or domain name and then double-click on it. You will be taken to the Creation screen. From there you create the domain or data element, activate it, and then press the Back button to return to where you were.
What follows is the procedure for adding fields to a transparent table without first creating the domains and data elements.
Start the ScreenCam "How to Create a Transparent Table Without Preexisting Domains and Data Elements" now.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}