I just tried Walter's Meester Tax RIBuilder and it works very fast. I need to test bad conditions, though.

>Well, GetKeyIndexExp() is also one of the things that can be done once
>
>As to the escape-thing, I handle that very simply. the runtime does not let you escape, IDE does and there I have a routine that rolls back if necessary after I have debugged it
>
>As I remember, the code from Doug showed a simple RI. It was not meant to be performant, only to show the basic techniques
>
>Also, keep in mind that debugging RI, cancelling RI routines, sometimes makes vfp go bezerk. You have to completely exit vfp and start all over
>____________________
>
>>Hi Gregory,
>>
>>Analyzing it right now with the help of Martin's Jindra Coverage Profiler utility. The most time is spent in GetKeyIndexExp routine, then follows aSessionEnvironment methods.
>>
>>>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...