Conversion Process
Conversion Process
The following example shows the steps necessary for a conversion
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 therefore contains an active version (where the field has a length of 60 places) and a revised version (where the field only has a length of 30 places) of the table.
The active version of the table is created 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 table is converted in a series of 7 steps.
Step 1: Set Lock
The table is locked 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.
Step 2: Rename Table
The table is renamed 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 in the database a table named QCMTAB already exists (for example, from a previous conversion attempt), this table is deleted before renaming the table.
Step 3: Activating Tables
The revised version of the table is activated in the ABAP Dictionary. Thus the ABAP Dictionary contains only one active version of table TAB, in which field 3 has a length of 30.
The table TAB is created in the database with its new structure under the name QCM8TAB. In addition, the primary index of the table is created 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, however, contain any data.
Step 4: 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. Before converting large tables, you should therefore 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 about 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 therefore 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. In general it is not possible to determine in advance which record this will be. In such a case, you should clean up the data of the table before conversion.
Step 5: Delete the QCM Table
The data in table QCMTAB is no longer required at the end of the conversion. The table is therefore deleted, provided that 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, table QCMTAB is kept for safety reasons.
Step 6: Rename Table and Create Secondary Indexes
Table QCM8TAB is renamed to TAB. The secondary indexes on the table defined in the ABAP Dictionary are newly created in the database. The views on the table that were deleted in the first step are also newly created in the database.
Step 7: Remove the Lock
The lock set at the beginning of the conversion is removed.
The table data is only consistent again once 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 may not be running during production. At least all the applications that use the table to be converted must be deactivated.
If the conversion terminates, the table stays locked is a reset log is written. 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 terminates (see
Conversion Problems), you can find the place where the conversion terminated in the reset log (last step to be executed).You must clean up terminated conversions! Programs that access tables might otherwise not execute correctly. 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 (see
Continuing Terminated Conversions).
The conversion process described is valid only for transparent tables. For
See also:
Conversion Problems Finding Terminated Conversions
