Example of Conversion

The following example explains how the system converts the table when you change its definition in the ABAP Dictionary.

Initial Situation:

Table TAB was changed in the ABAP Dictionary. At this time, the length of a field (Field 3) was reduced from 60 to 30 places. The ABAP Dictionary contains an active version (where the field has a length of 60 places) and a revised version (where the field has a length of 30 places) of the table.

The system creates the active version of the table in the database, that is, Field 3 currently has 60 places in the database. Two secondary indexes that were also created in the database are defined in the ABAP Dictionary for the table. The table already contains data.

Reducing the length of a field results in a table conversion. The following seven steps describe the table conversion in detail.

Set Lock
The system locks the table against further structural changes. This lock mechanism prevents a new structural change from being made before the conversion has finished correctly.

All the views that use the table are deleted from the database.
Rename Table
The system renames the table in the database. All indexes on the table are deleted. The name of the new table consists of the prefix QCM and the table name. The name of the temporary table for table TAB is thus QCMTAB. If a table named QCMTAB already exists in the database (for example, from a previous conversion attempt), this table is deleted before the table is renamed.

Activating Tables
The revised version of the table is activated in the ABAP Dictionary. The ABAP Dictionary now contains only one active version of table TAB, in which Field 3 has a length of 30.

The system creates table TAB in the database with its new structure under the name QCM8TAB. In addition, the system creates the primary index of the table in the database. The structure of database table QCM8TAB thus corresponds to the structure of table TAB in the ABAP Dictionary after this step. The database table does not contain any data.

Reload Data
The data is copied from table QCMTAB to table QCM8TAB (with the ABAP command MOVE-CORRESPONDING). After this step, the data is present in both tables, requiring additional space.

Caution
Before converting large tables, you must check whether the relevant tablespace has enough space left.

You can find information about how existing entries are handled in a field when the field type changes in the ABAP documentation concerning the MOVE-CORRESPONDING statement.

When you copy data from table QCMTAB into table QCM8TAB, a database commit is stored after 16 MB. The conversion process needs 16 MB of resources in the rollback segment.

When the length of a field is reduced, the extra places are truncated when the field is reloaded. When the length of a key is reduced and there are several records whose new key cannot be distinguished, only one of these records can be reloaded. It is not possible to determine in advance which record is kept by the system. In such a case, you must clean up the data of the table before the conversion.

Delete the QCM Table
The data in table QCMTAB is no longer required at the end of the conversion. The table is deleted if all records could be copied from table QCMTAB into table QCM8TAB. If duplicate records appeared in table QCM8TAB, for example, because the key of table TAB was shortened, the system keeps table QCMTAB for safety reasons.
Rename Table and Create Secondary Indexes
Table QCM8TAB is renamed to TAB. The system recreates the secondary indexes for the table defined in the ABAP Dictionary in the database. The system also creates the views on the table that were deleted in the first step again in the database.
Remove the Lock
The lock that was set at the beginning of the conversion is removed.

Note

During the conversion process, the table is not available in the database under its original name. The table data is consistent again only if Step 4 has been completed. For this reason, programs must not access the table while the conversion is running. Otherwise a program could behave incorrectly when reading the table since some of the records were not yet copied back from the temporary table. For this reason conversions are not running during production. At least all the applications that use the table to be converted must be deactivated.

If the conversion aborts, the table stays locked and the system writes a reset log. Each successful step of the conversion is recorded in this reset log. The restart log is deleted together with the lock when the conversion has been completed. If the conversion aborts, you can find the place where the conversion terminated in the reset log (last step to be executed). For more information about some of the problem, that can occur, see Conversion Problems .

Caution

You must clean up terminated conversions.

Otherwise problems can occur with programs that access this table. You must find out why the conversion terminated (for example overflow of the corresponding tablespace) and correct it. You must then continue the terminated conversion. For more information, see Continuing Terminated Conversions .

Note

The conversion process described is valid only for transparent tables. For pooled and cluster tables , the system creates a database table with the name QCM<table_name>, corresponding to the structure of the pooled/cluster table and copies the data to this table. Then the data is deleted from the physical table pool/table cluster. Finally, the data is copied from the QCM table back to the physical table pool/table cluster according to the new table definition.