James,

The process runs fine outside COM, but under COM business objects instantiate differently. I fooled the process into believing it was in COM and it helped some. Right now I can't even get a CApplicationCOM subclass with no modifications to instantiate correctly.

Thanks

Rex



>>James,
>>
>>What I ended up doing was changing the CDataSession property from CPrivateSession to CDefaultSession, at least then, the event can see all the data.
>>
>
>>>
>>>This would be a great time for Kevin to jump in...
>
>I see Kevin did jump in, and of course his reasoning is solid. Each bizobj should be an entity unto itself, unless you need some sort of branching logic that only the data can return... At any rate, from my experience, dubugging COM objects is a royal pain in the toosh. If you are having problems with an object, use the event log, otherwise the strtofile function is pretty handy. In my last fulltime job (yuck) I wrote alot of COM objects to expose the application data to the web. Since I'm not a good ASP programmer, I worked with a web developer who knew nothing about VFP. When things didn't work as expected, I always blamed it on the ASP and she always blamed the COM object. We didn't get along very well. At any rate, your best bet is to get things working outside of COM, and then run it inside COM.