Файл: BC430_EN_Col62_FV_Part_A4_-_ABAP_Dictionary.pdf

Unit 6: Changes to Tables

BC430

If the table does not contain any data, it is deleted on the database and created
again with its new structure. If data exists in the table, there is an attempt 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.

Figure 60: Conversion Process 1

The following example shows the steps carried out by the system during a
conversion.

Starting situation:

The table TAB was changed in the ABAP Dictionary. The

length of field 3 was hereby reduced from 60 to 30 places.

The ABAP Dictionary therefore has an active (field 3 has a length of 60 places)
and an inactive (field 3 still has 30 places) version of the table.

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

The table already contains data.

148

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Changes to Tables

Figure 61: Conversion Process 2

Step 1:

The table is locked against further structure changes. If the conversion

terminates due to an error, the table remains locked. This lock mechanism
prevents further structure changes from being made before the conversion has
been completed correctly. Data could be lost in such a case. Furthermore, all
views dependent on the table are inactivated and therefore blocked.

Step 2:

The table in the database is renamed. All the indexes on the table are

deleted. The name of the new (temporary) table is defined by the prefix QCM
and the table name. The name of the temporary table for table TAB is therefore
QCMTAB.

2006/Q2

© 2007 SAP AG. All rights reserved.

149

Unit 6: Changes to Tables

BC430

Figure 62: Conversion Process 3

Step 3:

The inactive version of table TAB is activated in the ABAP Dictionary.

The table is created in the database with its new structure and with the name
QCM8TAB. The primary index on the table is also created in the database. The
structure of database table QCM8TAB is the same as the structure of the active
table in the ABAP Dictionary after this step. The database table, however, still
does not contain any data.

The table therefore does not exist in the database with its original name during
conversion. Programs that access this table therefore cannot be executed.

You

should therefore always make sure that no applications access the table to be
converted during conversion.

150

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Changes to Tables

Figure 63: Conversion Process 4

Step 4:

The data is loaded back from table QCMTAB to table QCM8TAB (with

MOVE-CORRESPONDING). The data is in both tables after this step. When
you reduce the size of fields, for example, the extra places are truncated when
you reload the data.

Since the data is in both tables QCM8TAB and QCMTAB during the conversion,
there are greater storage requirements during conversion. You should therefore
check whether there is sufficient space available in the corresponding tablespace
before converting large tables.

There is a database commit after 16 MB when you copy the data from table
QCMTAB to table QCM8TAB. A conversion process therefore needs 16 MB
resources in the rollback segment. The existing database lock is released with
the Commit and then requested again before the next data area to be converted
is edited.

When you reduce the size of keys, only one record can be reloaded if there are
several records whose key cannot be distinguished. It is not possible to say which
record this will be. In such a case you should clean up the data of the table before
converting.

2006/Q2

© 2007 SAP AG. All rights reserved.

151

Unit 6: Changes to Tables

BC430

Figure 64: Conversion Process 5

Step 5:

Table QCMTAB is deleted.

Step 6:

Table QCM8TAB is renamed to TAB. The secondary indexes defined in

the ABAP Dictionary for the table are created again. The views on the table that
we deactivated in the first step of the conversion are reactivated on the database.

Step 7:

The lock set at the beginning of the conversion is removed.

•

If the conversion terminates, the table remains locked and a restart log is
written.

•

Caution: The table does not exist in the database with its original name
during conversion. Programs may not access the table during conversion.

Conversions should not run during production!

You must at least

deactivate all the applications that use the tables to be converted.

•

You must clean up terminated conversions.

Programs that access the

table will otherwise not run correctly. In this case, you must find out why
the conversion terminated (for example, overflow of the corresponding
tablespace) and correct it. Then continue the terminated conversion.

152

© 2007 SAP AG. All rights reserved.

2006/Q2