Thomas,

Excellent points! We would need to ping point the problem exactly. I'm going to share this thread with the group and may be my colleague can find all the details we're looking for. Right now I'm working on several other things simultaniously and can not do this kind of measurements.

>Hi Nadya,
>
>>Here is statistics:

>>
>>* After changing the class in VFP8:
>>The Save method for Employee_queue_activity_bizobj1 takes 0 sec.
>>The Save method for Transresolutioncodesbizobj1 takes 0 sec.
>>The Save method for Transpatientsbizobj1 takes 0 sec.
>>
>>* =========
>>
>>* After changing the class in VFP9:
>>The Save method for Employee_queue_activity_bizobj1 takes 6 sec.
>>The Save method for Transresolutioncodesbizobj1 takes 13 sec.
>>The Save method for Transpatientsbizobj1 takes 19 sec.

>
>With such numbers I'ld even forego the coverage profiler for first try<g>.
>I'ld build pre and afterhooks to be called bracketing Transpatientsbizobj1.Save() or where your timing code is now. For a first check I'ld stay with set trbetween on and debug - perhaps the offending line is visible long enough.
>
>If that doesn't work, I'ld create a coverage under 8 and 9 in the preHook and switch off in the postHook, read the coverages into tables and compare line timings directly: something like show me whenever vfp9 takes 500 (!) ms more. Should be easy to spot <g>. If the coverage file size/line number count is not identical, perhaps different version of the classes are used ?
>
>Are you sure the loading path is identical for vfp9 and 8 ?? My gut reaction would be to assume some classes take longer to load because a path is different, and perhaps you don't cache classlibs forcing access to the vcx on each load. Since mere is heavily into factories, that could be crippeling. But transactions are also a nice bet.
>
>regards
>
>thomas