>When functionality built into some object in framework and does not require extra programming for users of that object - it is even MUCH more better than development using some weird session objects used by hacking ways (natural purpose of session object - to use together with forms).
>>
>
>I disagree with this statement entirely. I don't think session objects should be used with forms.

You did not understood my point of view. I'm not saying that data session objects should be used by CreateObject and than added to form when said "natural purpose of session object - to use together with forms". I agree with 2 your following points and my suggestions were exactly the same things that you just described in details. This my statement was about use of form private data sessions and do not use data session object as separate one.

>
>Session objects create datasessions. That and their small number of exposed PEMs make them perfect candidates for business objects/COM servers.
>

But not to use to organaze data sessions for forms - that was my point too. However, I also don't see benefits of use of this class for COM objects. Custom class have no additional functionality and any PEMS could be hidden so interface will not contain extra items. This is the same thing you have when saying about 'number of exposed PEMs' - you can make that any class will not contain any native PEMs exposed. Creating data session in COM object is not what is required too. Why and when we can face the problem when we require private data session for remote COM objects under MTS? If you provide me a real-life sample that makes some sense, than I will see that data session object is more beneficial for COM objects than other classes. Yet I see no difference but just a lot of talking around.

>Using them with forms presents two scenarios:
>1. Use AddObject/NewObject to add it to the containership of the form. If you do this, you kill one aspect of the session object. It no longer has its own datasession. It participates in the form's.
>2. Use CreateObject and then assign it to a form-level property. This presents a problem if you call methods within the session object. VFP automatically changes the datasession when you run code within an object. Since the form will still have focus, this could wreak havok with any bound controls because the datasession will have changed and any table they are bound to will probably not exist in the new datasession. Most controls but especially your grids, will be useless.