Deletion of BRF Objects

Use

Deletion of BRF objects can be regarded as a special case of saving (see Saving Data).

The following points form the basic idea in deletion:

• The OLD tables and OLD structures have the status of the database, in other words, the table entries to be deleted are in the database

• The CUR tables and CUR structures remain empty

The method SPLIT_TABLES of class CL_AUX_BRF that is called in the method SAVE, then creates the tables of the entries to be added, changed, and deleted. All tables are empty, except the table with the table entries to be deleted.

Deletion (like the create, change, and display activities) is started on the initial screen. In contrast to create, change, and display activities, there is no subsequent data screen following a deletion activity. The system remains on the initial screen.

The following methods belong to deletion:

· ENQUEUE

In deletion (like in create and change activities), you must lock the objects that you want to delete. You thereby ensure that the database remains consistent. This method has already been implemented sufficiently by the basis class.

For more information, see Method ENQUEUE.

· LOAD

With deletion, the method LOAD functions in almost the same way as with create, change, and display activities (see Method LOAD). The only difference is that the OLD tables and OLD structures are not copied to the CUR tables and CUR structures.

Extract from the source text:

IF mv_edit_mode <> '4'.

ms_brf142_cur = ms_brf142_old.

mt_brf144_cur[] = mt_brf144_old[].

ENDIF.

· IS_MODIFIED

The method IS_MODIFIED calculates the table differences or structure differences (as with save activities). The most important step here is filling the internal member table MT_CHANGED_TABLES.

For more information, see Method IS_MODIFIED.

· GET_TRANSPORT_OBJECTS

The method GET_TRANSPORT_OBJECTS functions in exactly the same way as create or change. The potentially affected tables are made known to the transport system by this method. Details (in other words, the concrete table entries) follow later on in other methods.

For more information, see Method GET_TRANSPORT_OBJECTS.

· SAVE_PREPARE

The method SAVE_PREPARE creates the concrete transport entries. You must ensure that a transport entry exists for each table line to be deleted. Particularly if the specialization table is "structure-like", the transport entry must be derived from the OLD structure, and not from the CUR structure (as is the case when creating or changing).

For more information, see Method SAVE_PREPARE.

You do not need to create an explicit "deletion request" for the transport system. Each entry in the transport system consists of the name of the table affected and the concatenated key of the deleted entry. If the transport system establishes that there is no entry (any longer) in the specified table for the corresponding key, this is automatically interpreted as a deletion request. If the entry exists, the contents are simply transported.

· SAVE

Saving is executed in almost the same way as with create or change activities. The only difference is that it makes sense to delete entries of "structure-like" tables explicitly, as a service like SPLIT_TABLES is not available here.

For more information, see Method SAVE.

Sample source text:

CASE mv_edit_mode.

WHEN '1' OR '2'.

MODIFY tbrf142 FROM ms_brf142_cur.

ms_brf142_old = ms_brf142_cur.

mt_brf144_old[] = mt_brf144_cur[].

WHEN '4'.

DELETE tbrf142 FROM ms_brf142_old.

ENDCASE.

Description of the above source text:

In edit mode 4 (activity type Delete) it is easier to delete structure-like objects directly by way of the DELETE statement instead of using the methods split_tables and save_tables.