An ABAP program can correctly access a database table only when the runtime object of the table and its structure in the database are mutually consistent. Changes in tables must be reflected in the database structure of the table.
However, the database structures need not be modified for certain changes to the ABAP Dictionary, such as changes in the order of the non-key fields in the ABAP Dictionary. In such cases, the changed structure is simply activated in the ABAP Dictionary and the database structure remains unchanged.
HOW IS THE STRUCTURED ADJUSTED?
Any change in definition in the ABAP Dictionary should evoke a matching adjustment to the database tables. You can do this by
deleting the database table and re-creating it; changing the database catalog; or converting the table.In the first method, the database table is first deleted. Next, the inactive table in the ABAP Dictionary is activated and re-created on the database.
The second method involves changing the definition of the database table. It does not result in any loss of data.
The third method requires the maximum time for adjusting a structure as it deals with the conversion of tables. If the table does not contain any data, it is deleted on the database and created afresh. However, if data exists in the table, the table structure is adjusted with ALTER TABLE. If the database system fails to make any adjustments, the structure is adjusted by converting the table.
CONVERSION PROCESS 1
Let us assume that the table TAB in the ABAP Dictionary is so modified that the length of its Field 3 reduces from 60 to 30 places. This results in an active table version where field 3 still has a length of 60 places and an inactive table version where field 3 has 30 places.
As the active version of the table was created on the database, the field 3 in the database table still has 60 places. A secondary index with the ID A11, which was also generated in the database, is specified for the table in the ABAP Dictionary. This disparity between the tables can be removed through conversion.
CONVERSION PROCESS 2
The first step is to lock the table against further structure changes. This is because any such changes would result in loss of data. Additionally, all views dependent on the table are inactivated.
The next step is to rename the table in the database and delete all the indexes on the table. The name of the temporary table that is newly created is assigned the prefix QCM, followed by the table name. Therefore, in the example here, the name for the temporary table is QCMTAB.
CONVERSION PROCESS 3
The third step involves activating the inactive version of table TAB in the ABAP Dictionary. This table is then created in the database with the new structure and the name QCM8TAB. The primary index on the table is also generated in the database.
However, the newly created database table does not contain any data. As a result, it does not exist in the database under its original name during conversion. If a program were to access the table, it would not be able to execute. Therefore, it is essential that applications do not access the tables during conversion.The third step involves activating the inactive version of table TAB in the ABAP Dictionary. This table is then created in the database with the new structure and the name QCM8TAB. The primary index on the table is also generated in the database.
However, the newly created database table does not contain any data. As a result, it does not exist in the database under its original name during conversion. If a program were to access the table, it would not be able to execute. Therefore, it is essential that applications do not access the tables during conversion.
CONVERSION PROCESS 4
In the fourth step, data is copied back from table QCMTAB into table QCM8TAB so that both tables have the same data. This duplication necessitates more storage space.
When data is copied from one table to another, the system faces a database commit after 16 MB. As a result, the conversion process inevitably requires 16 MB resources in the rollback segment. This ensures that the existing database lock is released with the Commit and then requested again before the next data area to be converted is edited.
CONVERSION PROCESS 5
In the fifth step, table QCMTAB is deleted from the database.
Next, table QCM8TAB is renamed as TAB, the secondary indexes defined in the ABAP Dictionary for the table are re-created, and the views on the table deleted in the first step of the conversion are also activated again in the database.
Finally, the lock that was set at the beginning of the conversion is deleted. If the conversion ceases, the table remains locked and a restart log is written.
POSSIBLE PROBLEM DURING CONVERSION
Another problem is that if you shorten the key of a table, you will be unable to distinguish between the new keys of the existing records of the table. When you reload the data from the temporary table, only one of these records can be accessible.
The third problem deals with invalid change of type. As the ABAP statement MOVE-CORRESPONDING is used during the conversion process, only those type changes that can be executed with MOVE-CORRESPONDING are feasible.
RESUMING TERMINATED CONVERSION
If a conversion terminates midway, the table cannot be edited with the maintenance tools of the ABAP Dictionary. You require transaction SE14 to resume the process. You can use analysis tools such as the object log and the syslog to determine the cause of the error and the present state of all the tables involved in the process. When conversions are terminated, you can use either of the two options in the database utility, Continue adjustment or the Unlock table.
The Continue adjustment option allows you to resume the conversion from where it was terminated.
However, the Unlock table option only deletes the existing lock entry for the table. You must not use this option if the conversion gets terminated in step 3 or step 4 when the data only exists in the temporary table.
APPEND STRUCTURES 1
Append structures allow you to append fields to an SAP standard table without the need to modify the table definition.
A single append structure is always assigned to exactly one table. A table, however, can have several append structures.
When a table is activated, the active append structures for that table are located and their fields appended to the table.
If an append structure is created or changed, the table to which it is assigned is activated and the changes take effect in the table. Like all structures, the append structure also defines a type that can be used in ABAP programs.
APPEND STRUCTURES 2
Append structures are created by customers in their own namespace. As a result, they are protected against overwriting during an upgrade.
A conversion is not essential when you add an append structure or insert fields into an existing one. This is because, following Release 3.0, the order of the fields in the ABAP Dictionary can differ from that on the database. The structure is adjusted according to changes made in the database catalog. Therefore, when the table is activated in the ABAP Dictionary, its definition is changed and the new field is appended to the database table. You can import new versions of the standard tables during the upgrade.
APPEND STRUCTURES 3
After activating the new version of the SAP standard table, the new field is appended to the database table.
ENHANNCEMENT OF TABLES
This slide illustrates how a customer can enhance the structures and tables defined by SAP in the ABAP Dictionary.
One method is Customizing includes.
With this variant, certain places within a structure or tables are already reserved for enhancements. However, you need to create the associated Includes first.
The second method is the use of Appends.
With this method, any field without previous reservation can be appended to the end of structures or tables.
No comments:
Post a Comment