>Naomi,
>>
>>Well, the difference is that in the first case I insert records into Trans_Employees_Queues table and in the second case these records are already inserted. However, 4 hours and 10 minutes still don't make much sense. I'm thinking of commenting out the call to ProcessNewTrans in LoadNewTrans and see, if I still get the same 4 hours then running two processes independently. Both processes are subclasses of BusinessProcess class, which is based on Session class. In other words, if running them in the LoadNewTrans calls ProcessNewTrans sequence I create two datasessions. If running one, then another, we would not have two separate DS.
>
>Switching DS is quite fast - don't think that is responsible. My first gut feeling would be to check on rushmore: if data gets added, the .cdx is dirtyed and cached bitmaps HAVE to be read again - which can be painful if the table is large and the index is not candidate. Probably that or some other kind of thrashing of the fwk, since the difference is that great. Since different code is running, coverage is not exactly applicable: since you are a perf nut like myself I'ld reccomend instrumeting the code with timable call to a log. You can zoom into critical sections faster that way than trying to analyze the coverage of a 4H run.
>
>regards
>
>thomas

You're up to something. I switched Select-SQL to locate in LoadNewTrans (so we would use buffered data) and the process that originally runs 1h. now takes more than 2h. From the business logic this switch is correct, but I'm saddened in such speed drop...