>
>In all our tables we have ModiType field with 3 possible values in it (A/C/D). These flags are updated in a complicated code. Another table has this field as well, so I thought, it would be a good idea to keep the same convention here. It looks like this update could not be done automatically on Table Level, so I have to put a special code in Delete method of the form...

Nadya,

Putting code in field/record validation and triggers is what I prefer. The advantage is that you have to put it in only one place. You may access/modify the table from a browse or any other form/procedure, the code is still there.

Now, back to your problem. It is unfortunate that the record validation does not fire on a delete (but then that is not the purpose of the record validation). The trigger on the other hand does not let you move off the record and does not allow you to update the record.

Three possible solutions come to mind
(1) batch.

Private ProcessingDeletedOnTable
ProcessingDeletedOnTable = TRUE
set deleted Off
update table set field ='D' where (field <> 'D') and deleted()
release ProcessingDeletedOnTable

&& modify record validation towards the end
if( type('ProcessingDeletedOnTable') <> T_UNDEFINED )
    if( ProcessingDeletedOnTable )
        && do not process the changed

Can be optimized by having a filtered index on ( Field <> 'D' and Deleted() )

(2) Have the delete trigger write the key or record number into another table (to be processed). Next you need either a batch run on specific times or a timer that processes the table and sets the D in the records that have been deleted. (same about ProcessingDeletedOnTable described in (1))

A combination of (1) and (2) is possible.
- have the filtered index
- have a timer fire at some intervals that processes the filtered index

(3) Also possible is that the delete trigger adds an object to _Screen(just prior to exiting the trigger) and passes the table name and the record number or key to the init of the Object. The Object would then have to wait for a sec or so, process the event and release itself (eg by returning FALSE from the init). Best is also to keep the filtered index just in case

(1) and (2) are not very clean. I like (3) the most since it is processed within a sec or 2 and because it needs to be coded only once