Triggers

Triggers are the most important objects of the system. They capture changes for LogReader, store records in history, set the subject table with system parameters of record, bind pair relations between local and remote and have many other features.

In DB are triggers defined for all user and some system tables. All triggers are created dynamically by special procedure for all tables at once.

INSTEAD OF INSERT

When row is inserting INSTEAD OF INSERT is triggered. From CONTEXT_INFO reads the current user. Analyzes inserting row and stores it into the table. During the analysis are solved integrity bindings to both local as well as for subscribed records from remote server.

AFTER INSERT

When row is inserted AFTER INSERT is triggered. From CONTEXT_INFO reads the current user. Row is stored in global_History as a set of records in a single TaskId. At the same time it is saved record to the table global_Subject.

AFTER UPDATE

When row is changed AFTER UPDATE is triggered. From CONTEXT_INFO reads the current user. Analyzes updated row and stores it into the table . During the analysis are solved integrity bindings to both local as well as for subscribed records from remote server. Row is stored in global_History as one or more records in a single TaskId.

At the update level is solved IsDeleted flag (See INSTEAD OF DELETE). At the same time it is updated appropriate row in the table global_Subject.

When you update row, the counter Version is increased by 1. The version number increases automatically after row update. Version number cannot be overwritten by user, it is protected by trigger. Versioning starts from number 1 when you create a row.

INSTEAD OF DELETE

Physical delete of row from the user tables are prohibited. Physical record deletion prevents DB INSTEAD OF DELETE trigger on the DB level. Record cannot be deleted by any application .

Instead of physical delete is used IsDeleted flag, which is in each user table. This flag is set to True instead of row deleting. If you perform a DELETE FROM, physical delete is not performed but the flag IsDeleted is set to True. If this flag is set, the row is deleted and cannot be renewed. When you try to renew it, exception is thrown.

At the moment when IsDeleted flag is set to True, trigger checks foreign keys of depending tables and their rows in relations. If would be occurred foreign keys conflict during a standard physical delete, trigger ensures that this conflict occurs even when the flag IsDeleted is set to True and an exception is always thrown (for TRY of the client) .

Setting the IsDeleted flag to True has thus the same behavior as the physical removal of the row. Records that are flagged IsDeleted=True, the client application should not be published. If the next delete attempt is made on logically deleted row, then this is a bug in the client application or a deliberate intervention direct to the DB. In this case this attempt is stored into global_SpyLog and the mail alert is sent to system administrator with detailed information.