Conversion Problems
Some of the problems that occur during conversions are listed below. For more information about the conversion process, see Conversion Process .
Termination due to Tablespace Overflow
Since the data is present in both the QCM8 table and the QCM table during the conversion, more space is required when the system performs the conversion. Before converting large tables, you must check whether there is enough space in the tablespace concerned.
If there is a tablespace overflow when the system reloads data from the QCM table into the QCM8 table, the conversion terminates at this point.
If this happens, you must extend the tablespace and resume the conversion in the database utility with Continue adjustment.
The system then continues the conversion at the point at which it terminated. For more information, see Continuing Terminated Conversions .
Deletion of a Client Field
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 resulted in records having the same key, only one of these records can be reloaded into the table. Which record this is depends on the order in which the records are reloaded to the table. 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.
Data Loss when Keys are Shortened
If a table key is shortened (for example, by removing or shortening the field length of key fields), the system can no longer distinguish the new key of the existing table records. When data is reloaded from the QCM table, only one of these records can be reloaded into the table (since the database does not allow duplicate records).
It is not possible to know in advance which of the records can be reloaded. If there are records that you want to reload, you must clean up the table before the conversion.
Type Conversion not Possible
During a conversion, the data is copied from the QCM table back to the QCM8 table using the ABAP command MOVE-CORRESPONDING. A type can be changed during a conversion only if this can be executed with MOVE-CORRESPONDING. If a field type cannot be changed using MOVE-CORRESPONDING, the conversion terminates when the data is reloaded into the QCM8 table.
If the conversion terminates because a type change is not supported, you must restore the old state before the conversion.
To do this, you need to delete the QCM8 table in the first step and rename the QCM table to its original name. In the second step, you have to remove the lock in the database utility with Unlock table. Then you must reconstruct the runtime object for the table using the database utility (see Editing Database Tables and Indexes ) and return the table definition in the ABAP Dictionary to the state it had before the conversion. The last step is to activate the table in the ABAP Dictionary.
Problems occurring during type conversions depend on the contents of the field concerned.
You reduce the accuracy of a DECIMAL field (the number of places before the period). If there are entries in the field in which all positions before the period are used, a termination occurs when the records are reloaded into the table. If there are no such entries, the records can be reloaded.
Termination during Conversion of Pooled or Cluster Tables
When a pooled or cluster table is converted (see Pooled and Cluster Tables ), the system creates the QCM table in the database as a transparent table and the data from the pooled or cluster table is copied to it. There is an upper limit for the number of fields in a database table depending on the database system used.
It is not possible to convert pooled and cluster tables if the number of fields in the pooled or cluster table exceeds the maximum number of fields possible in a database table.
See also:
Continuing Terminated Conversions