Hi Gregory,

I think, instead of array I may have a table (either free or part of database), which would be used and which would contain all the necessary info. This would give me desired speed increase.

>hi Nadya,
>
>Which parts are slow ? Have you done a coverage profiler ?
>
>At first sight, (but you need to profile it first) I'd say that looping/scanning through the relation is something that is done many times where imo it should be done once
>
>There are a couple of ways to get around that
>(1) each time the RI is changed, update an internal free table.
>When a trigger fires you can use the CursorGetProp('SourceName')) and the trigger type to seek() and scan rest while.
>That will give you the routines you need to fire
>
>I told (wrote, this is) you I use a prebuilt array and work my way through it with eval(), which isn't slow
>
>(2) Perhaps even simpler is to generate a specific function for each table+triggertype
>Use (1) but build a cursor and generate the routines from the cursor
>
>

>function Customer_Update()
>    && you'll need this to debug, each time you select something else, you must reset it when you exit the routine
>    assert 'CUSTOMER' ==  CursorGetProp('SourceName')
>
>    local Success
>    Success = TRUE
>
>    do case
>    case !m.Success
>
>    case m.plError
>       Success = FALSE
>
>    case !Cascade_Update('Customer', 'Childx', 'bintoc(cust_id)', ..., ...)
>       Success = FALSE
>
>    case !Cascade_Update('Customer', 'Childy', 'bintoc(cust_id)', ..., ...)
>       Success = FALSE
>
>       .... etc
>
>    endcase
>
>    return m.Success and !m.plERror
>endfunc
>*------------
>

>
>You'll end up writing your own ;-)
>______________________________________________________________________________________
>>Hi everybody,
>>
>>I was trying to use Steve Saywer's/Doug Henning's RI builder.
>The idea of using just one simple procedure instead of lots of multiple convoluted procedures is very appealing.
>I made bunch of modifications in Doug's code trying to optimize this procedure. Perhaps, I made it worse than before.
>The code originally used Select-SQL for restrict triggers (insert/update/delete). I switched to IndexSeek.
>The code also looped through array of relationships, I changed it slightly to use ASCAN.
>In my opinion these changes should have speed the procedure up. Anyway, comparing with the old native RI it seems to be much slower.
>I'm thinking that I may use KEYMATCH instead of INDEXSEEK. Would it make it run faster?
>Bellow is the code as I have right now. I would appreciate if you can point me to the problematic pieces.
>I also tried to incorporate Glen's idea of save/restore environment logic. However, it adds a layer of complexity, which is probably undesired...