>>>Two options
>>>(1) for runtime, is to open all the tables at startup of the app in a private datasession
>>>
>>>(2) in the trigger open them if you need them, then after rollback/end transaction only close them if it is the default datasession. That way forms will go faster and when you develop, the default datasession will be cleaner
>>>
>>>

>>>#define PRIVATEDATASESSION ( set('DataSession') > 1 )
>>>....
>>>  if( _triggerlevel = 1 )
>>>      if (   )
>>>          rollback
>>>      else
>>>         end transaction
>>>      endif
>>>
>>>
>>>     if( PRIVATEDATASESSION )
>>>        close all table opened by me
>>>     endif
>>>

>>
>>Good idea. So far I ran my tests in the default DS. I would add that check, thanks.
>
>_________________________
>hey, you're welcome
>
>I close all the tables when I exit the top level of my RI whether private datasession or not. Neither do I open all the tables at the start of the app
>
>When you have done some tests with say (1) and (2) would you give some feedback ? ie compare (0) nothing, (1) and (2) local on a network. If there's a significant difference, I may switch to scenario (1) or (2) whatever is the most performant. Thanks

Gregory,

I'm only going to try number 2. I'm going to run just few tests, because this issue is taking too much of my time. We discussed this problem today on our programming meeting. I told, that I want to use help of one other programmer and want to do a parallel programming with him. Basically, it's obvious to me that there is a bug in the existing code, which I need to trace first. Why I know about the bug? Well, it's easy: in my tests I was changing the value of cEntered_User field. This field is not engaged in any relations, but yet I ended up with lots of tables open. So there is clearly a bug which we have to trace. Once this done, I want to modify the builder, so it would create a table in the DBC() path called RIDefinitions. In this table I would only put those RI that have R or C. E.g. this table will have fewer records than number of relations, because more than half of them have Ignore for all three types. I also put Key expressions for both parent and child, so I would not need to resolve them at run-time. So all these changes are going to speed up the trigger's code. I still would have just one procedure.

That's my plan, now I'm going to call my colleague and start implementing it.

Thanks again for lots of useful ideas.