Hi!

>Vlad,
>
>>...(natural purpose of session object - to use together with forms).
>
>I'd say the natural purpose of the session object is to better provide for encapsulation without any thought about whether it's used with forms or without. Session-based objects can easily be called from strictly procedural code that has no form associated with it, so I do not agree that its main purpose is for use with forms.
>

As about encapsulation, I already made the point that data sessions look quite weird from the OOP point of view. Why not make VFP built-in cursor object similar to ADO object? IMHO this way is much more obvious and simple for use than handling old-style workareas. Yet I agree with you, but I don;t like this way amnd still use my own wrapper objects that use unique alias names for tables.

>Objects based on Session can easily be called from other objects, such as a COM server that instantiates multiple business objects in one of its methods. No forms involved there.
>

What the difference between use of session object and custom object in COM server objects? My points are:

- Sinse COM server is statless, we have no reason to think about data sessions, because all tables used in previous COM server method call can never cause conflict in next method call. Of course, if COM server made correctly - when it is really stateless. Why we require private data sessions here? Are you saying that business rules for a single COM server call are so complex that we require to divide them to different routines, each with its own data session just because they might conflict with each otehr? I never met such complexity of business rules.
- Because all native PEMs of any VFP object could be hidden, the point that session object have less PEMs makes no sense - we can use custom object with the same success and size of the interface part transferred over network after hiding all useless PEMs.


>Session is also very useful for encapsulating blocks of old-style procedural code (which perhaps may open tables in certain work areas) as a first step in fast migration of older projects.

I can make the same with good success using our environment controlling class. It remembers all aliases opened in the areas and their properties, after routine call it restores environment to previous state - closes any extra opened aliases, restores order/filters/bufferig mode, warns developer if some alias closed in routine (that is usually restricted). By such way, from one side, you have a tool to close extra opened aliases, from the other side, you will see what is wrong in your routine and what is needed to fix in it to use in most places. Note that there are situations when you need to use in routine already opened alias. With private data session this is possible, but you will require to switch between data sessions inside of routine taht is quite the mess.

I will appreciate your answers because it is always good thing to share experiense using such discussions.