Hi!

>>As about encapsulation, I already made the point that data sessions look quite weird from the OOP point of view.
>
>The Session class fits quite well into an OOP model. Maybe you are referring to data sessions in general in your statement above? I think of the private data session as the "walls" of the Session object. Inside those walls, anything goes -- without any concern for what's happening outside the walls.
>
>>- ... 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.
>
>I mentioned an example of a COM server method that instantiates and calls into one or more business object classes based on Session. This is done without any fear or complexity of conflict with anything else happening in that COM server method, and the same Session-based BO can also be used in multiple other ways with no changes to code. That's the importance of encapsulation.
>
>>- 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.
>
>Maybe Microsoft thought it was a good idea to provide a class that required no additional work to accomplish that -- I think you made the point earlier that it's best to have classes that save the developer additional work and coding.
>

I understand all these above point. I meant that instead of maintaining old-style of working with workareas, it would be much better to have all cursors opened as objects. Say, you open cursor as object. Than SELECT objectname command will select object as current for all further commands. Object also could be referenced as alias in commands. BUT, such object is not part of the work areas, it will not appear there. You can open them as many as you want, but thay copuld be opened as local variable and closed automatically just when gone out of scope. Properties of such object - fields of cursor. Methods could incorporate many commands and properties that we get yet using cursorgetprop() and dbgetprop() functions. I see not diificulties to implement this in VFP just now. And no conflicts with other cursor objects at all! More, such object can contain events that could be defined (we already have database events - how much it gives - you know). And it is much more simple to understand for new VFP developers than session object and data sessions. All we have now - wrapper around non-OOP workareas.

One question - WHY??? Why not implement such obvious idea? Why do this by way using idea of working around old things?

>>>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).
>
>For those who don't already have an environment controlling class, the Session class handles it all with no additional coding. Switching to Session would greatly simplify that part of your framework and might provide extra speed as well.
>

Right. It looks like I did not get weird results yet in my COM/business objects. Maybe it is good idea to move to session object soon.