Deleting Records

In DataView you can delete records temporarily and finally. DataView uses this two-level procedure to protect the data of your application from unintentional delete operations.


Deleting Temporarily

In DataView deleting temporarily means that the record is not physically removed from the data base when interactively deleting using one of the standard functions. It is only marked as deleted, similar to delete operations on a hard-disk. This is done by resetting the sign-bit of the internal ident number, which is used to identify each record within a DataView table.

Thus all DataView standard functions check the value of the internal ident number for its positive sign at each data base access. For your own userexits, which directly access the data base via the EPSQL interface, you must organize these checks yourself. This means that all SQL statements should contain a WHERE condition checking for a positive ident number.

To allow you to find temporarily deleted records even after a system crash, DataView logs all delete processes in a user specific delete log file. This file can be found in the < lck> directory. DataView creates this file in the initialization phase and removes it when the program is closed normally. If DataView detects old delete log files in the initialization phase, DataView automatically transfers the entries of the log file into the trash-basket widget . For in DataView several users can work under the same name at the same time, the name of this file is expanded by the prefix "T_" plus the identification code of the user (UIC) and a letter of the alphabet (e.g. "T_100.A"). This allows a maximum of 26 users to work under identical names simultaneously.

As opposed to deleting finally, in case of temporary delete operations you can cancel the delete process with the help of a return code different from zero in the pre_action-userexit for temporary mode for each individual record. This means that your application has to execute all requests and checks that are to be done prior to deleting a record, must be already done when temporarily deleting the record. Thus you prevent that a record not released for deleting gets into the trash-basket widget at all.

You can influence the behavior of DataView for temporary delete processes by setting the check and delete flags during the definition of DataView relations, DataView types, or DataView constraints. Setting these flags is useful to secure the referential integrity in the data model. You can determine whether a depending entity record is also deleted when deleting a DataView relations-, type-, or constraint record. Thus it is possible to control delete processes in complex relation structures. Depending deleted record are put into the trash-basket widget below the header record. The DataView rollback mechanism in the trash-basket widget remains effective.

The following functions are available for modifying the check and delete flags:

dal_dbi_mod_rel
check and delete flags at a DataView relation

dal_dbi_mod_type
check and delete flags at a DataView type

dal_dbi_mod_cns
check and delete flags at a DataView constraint


Rollback Temporarily Deleted Records

Temporarily deletes records can be restored any time by resetting the sign-bit of the internal record-ident number. To do so, only use the function dal_wdh_rol_tra, so that the entries in the delete log file are automatically removed by DataView.

For nested delete processes, the depending records moved to the trash-basket widget can only be rolled back via their header record.

Rolling back deleted records can be cancelled for each record by a return code different from zero in the pre_action-userexit for temporary mode. At program exit Dataview automatically removes all temporarily deleted.


Deleting Finally

In DataView, deleting finally means, that records are physically removed from data base tables.

Temporarily deleted records may only be finally deleted via the function dal_wdh_del_tra. Thus you make sure that the entries in the delete log file created by DataView are also removed. It is not necessary, however, that a record to be finally deleted has been previously deleted temporarily. Using the function dal_dbi_del_lis you can create userexits, which remove records directly and finally from data base tables.

As opposed to temporary delete operations, final delete operations cannot be cancelled at the pre_action-trigger for delete mode. This means that your application has to execute all requests and checks that are to be done prior to deleting a record, must be already done when temporarily deleting the record.

When finally deleting master records in entity tables you can influence the DataView logics for the treatment of related records by modifying a reference check flag. The corresponding function is dal_dbi_set_del. By default (reference check flag val = 0) DataView checks the master record to be deleted in an entity table for related records and additionally deletes all related records in relation- and type tables if they exist.

Attention! Only reset the reference check flag in exceptional cases and with great care. In case of error severe physical inconsistencies in the data model can be the result. Only the default setting (val = 0) guarantees a secure and transaction protected operation.

Other settings of the reference check flag are:

no deleting of relation references (val = 1)
In addition to the record to be deleted, in this case DataView removes all related records in the corresponding type tables, but not in the relation tables of the entity of the record. The records in the relation tables must be deleted by the application in the pre- or post-action-userexit for delete mode.

no deleting of type references (val = 2)
In addition to the record to be deleted, in this case DataView removes all related records in the corresponding relation tables, but not in the type tables of the entity of the record. The records in the type tables must be deleted by the application in the pre- or post-action-userexit for delete mode.

no deleting of relation- and type references (val = 3)
In this case DataView only deletes the record to be deleted, but not the related records in the corresponding relation- and type tables of the entity of the record. The records in the relation- and type tables must be deleted by the application in the pre- or post-action-userexit for delete mode.

The reference check flag should only be reset if for a great number of defined relations (especially for type relations) only a small percentage is really used and known to the application. This results in a clear performance gain, for delete transactions have to be performed in few tables only.

In this case you have to individually reset the flag for each record in the pre-action-userexit for Delete mode, because DataView automatically resets the flag to the default value val = 0 after each delete operation.


The trash-basket Widget

All records which a user deletes interactively, are temporarily stored in the trash-basket widget by DataView. Depending on the definition of the check value and the delete flag in the relations data, entity type and constraint data lists DataView there additionally stores the records related to the deleted record. The mask of the trash-basket widget contains all information, that uniquely refer to these records. The ident number of the trash-basket widget can be detected using the function dal_wdg_ret_tra.

The first two fields of the mask of the trash-basket widget always contain the same field entries as the first two fields of the mask, from which the record has been deleted. As a whole, the mask consists of the following fields you can refer to from within a userexit via the names specified:

ORIGIN.C_ID
stores the internal record-ident number of the deleted records

join.C_ID
stores the internal record-ident number of the corresponding master table if the record has been deleted from a relation mask.

TRASH.FATHER
stores the internal record-ident number of the parent element in the master table if the record has been deleted from a relation mask.

TRASH.TABORI
stores the name of the original table of the deleted record.

TRASH.TABJOI
stores the name of the join table of the deleted record if the record has been deleted from a relation mask.

TRASH.PREEXIT
stores the name of the pre-action-userexit of the mask the record has been deleted from.

TRASH.POSTEXIT
stores the name of the post-action-userexit of the mask the record has been deleted from.

TRASH.ELMNAM
stores the field contents of the last significant field of the deleted record. The entry is visible for the user as first field in the trash-basket widget.

TRASH.MASNAM
stores the name of the mask the record has been deleted from. The entry is visible for the user as second field in the trash-basket widget.