>>>>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.
_______________

Some rules need two functions, eg a restrict on a child insert implies a restrict on the parent update
_______________
about that tables open thing (cEntered_User field)

I have not gone through all the code, just throwing in some ideas, but opening tables that are not needed may have some causes

(1) open a related child table when there is no delete trigger
(2) open a realted parent table when there is no insert trigger

(3) open a related parent and/or child table for an update trigger when the index has not changed, eg

function _Trigger_Process_Relation_Parent_Update_Restrict
		lparameters	TRIGGERRELATION_PARAMETERLIST

	local Success, sOther, _error_msg, s, ParentValue
	Success = TRUE
	s = select(0)
	ParentValue = oldval(m.thisIndexExpr)
	
	do case
	case !m.Success
	
	case eval(m.thisIndexExpr) == m.ParentValue
		&& not changed                         &&& HERE, it falls through, not opening anything

        case !_TriggerOpen(@sOther, m.OtherTable, m.OtherTag )
		Success = FALSE
			
	otherwise
          ....
        endcase


       return (m.Success and NO_ERROR)