>>I'd like to see that demo... So, his bizob would be an out-of-process object that another bizob would connect to. The bizobj would send data to the proxy
>
>
>Well, actually the bizobj proxy would be on the form. It would connect to the remote bizobj and request data, could be for a specific 'entityid' or criteria. It would receive the return data as a string, XML structured best.
>
>>bizobj in xml or string data, and the proxy bizobj would convert it to a >cursor. Is that what you mean?
>
>Yes, converting the data to a cursor would be one way to do it. Or, the proxy could have properties for each field and populate their values with the data in the XML string. Depending on how you design it. You could also even desing your form object to connect to the BizObj at load time, request the XML string, build a cursor for the controls.
>
>This design eliminates the constant DCOM messages when binding to an object instantiated over DCOM. Also, if the object is being hosted in MTS it could be designed as stateless, and after it sends its data it would send a Commit to it's reference object and MTS would idel it. This is the strategy for scalable middle tier multithread bizobjs.
>
>Another advantage is, once the data is local it is much faster to navigate or manipulate. Moving from record to record wouldn't require any DCOM messaging, which it the aspect, I assume that makes your friends ap perform so poorly.
>
>BOb

Thanks BOb,

I'll pass this thread along.