>hi Nadya,
>
>Yes,
>
>Easiest = a table (generated, see the two scans)
>
>TableName
>TRigger type
>FunctionName and params
>
>There may more than one entry (Tablename + Triggertype)
>
>Select into array and Eval() your way through
>
>a small step further = turn the table into code
>One function per TableName + TriggerType
>Write the code to the db

I thought about it a little bit more.

1) I don't need to keep a table, I just need to use a good naming convention, say, table_Trigger.

2) I have some thoughts why I want to use one procedure per table and not procedure per trigger.

The code should be like this

lparameter tcTriggerType

if m.lcTriggerType = "UPDATE"
    * update  logic
     lcTriggerType = "INSERT" && to do the logic when our table is a child
endif

if m.lcTriggerType = "DELETE"
   *delete logic
endif

if m.lcTriggerType = "INSERT"
   if _triggerlevel = 1 or ....
      * insert logic
   endif
endif

But actually, after I came up with the idea of implementation, I'm thinking, I'm not going to implement it. Here is why:

1) For most operations we're doing one record change in a time, so the speed is irrelevant.

2) For batch processes we can disable triggers completely using glDontUseTriggers variable. Since we run the processes at night, if we code them carefully, we don't need additional checks on a database level.

3) For DataLoad we do need triggers in place. However, we're doing DataLoad process until we go life.

4) So, we face the speed problem only on Import Data stage. Does it justify me changing the code and generate procedure per table - I think, it doesn't.

The speed I have now is acceptable, in my opinion. It's about 30-40% slower than native code. Originally it was ~10-50 times slower.