Changes to Database Tables

ABAP programs can only access a database table correctly if the runtime object of the table is consistent with the structure of the table in the database. Each time the table is changed in the ABAP Dictionary, the system checks during the activation (when the runtime object is updated) whether it has to adjust the database object to the changed ABAP Dictionary definition of the table.

 

The database structure does not have to be changed for certain changes to the ABAP Dictionary. For example, you do not have to change the database structure when the order of the fields (except key fields) in the ABAP Dictionary is changed. In this case, the changed structure is activated in the ABAP Dictionary and the database structure remains unchanged.

 

 

Structure Adjustment in the ABAP Dictionary

The database table can be adjusted to the changed definition in the ABAP Dictionary by doing one of the following:

• Deleting the database table and creating it again. The table in the database is deleted, the inactive table is activated in the ABAP Dictionary, and the table is created again in the database. The existing data in the table is lost.
• Changing the database catalog ALTER TABLE. The definition of the table in the database is simply changed. The existing data is retained. However, indexes of the table may have to be built again.
• Converting the table. This is the most time-consuming way of adjusting a database table.

 

If the table does not contain any data, it is deleted from the database and created again with its new structure. If data exists in the table, the system attempts to adjust the structure with ALTER TABLE. If the database system used is not able to do so, the structure is adjusted by converting the table.

 

Conversion is the most resource-intensive method of adjusting structures. However, structural changes involving changes to the database catalog can also result in costly internal data reorganizations in some database systems. You must not adjust the database structure during production. All applications that access the table must be deactivated during the structural adjustment. Since the table data is not consistent during the structural adjustment (in particular during conversion), programs may behave incorrectly when they access this data.

 

The Table Conversion Process

The procedure actually used by the system in a particular case depends on the following:

• Type of structural change
• Database system used
• Whether or not data already exists in the table

 

The following example illustrates the steps carried out by the system during a conversion:

 

In the figure, the table TAB was changed in the ABAP Dictionary. The length of field 3 was reduced from 60 to 30 places.

 

As a result, the ABAP Dictionary has an active (field 3 with a length of 60 places) and an inactive (field 3 with a length of 30 places) version of the table.

 

The table in the database corresponds to the active version in the ABAP Dictionary, which means that field 3 currently has 60 places in the database. A secondary index with the ID A11, which was also created in the database, is defined for the table in the ABAP Dictionary.

 

The table already contains data.

 

 

Conversion Errors

Possible Problems During Conversions

• Tablespace overflow
• Data loss if key is reduced in size
• Invalid change of type

 

As the data exists in both the original and temporary tables during conversion, the storage requirements increase. If the tablespace overflows when you reload the data from the temporary table, the conversion terminates. In this case, you must extend the tablespace and start the conversion in the database utility again.

 

If the client field is removed from a client-specific table, it is no longer possible to distinguish the new key of records from different clients.

 

If deleting a client field has resulted in records having the same key, only one of these records can be reloaded into the table. The order in which the records are reloaded to the table determines which record this is. You cannot be sure that the reloaded records come from only one client. In such a case, you must clean up the table before the conversion.