Ed,

>I'm afraid, you misunderstand me. If your entire code is datapointer-independent (i.e. doesn't depend on record pointers location before any call) then you don't need in private datasession in any point of your code, because you cannot affect any other part of your application by moving data pointer in specific part of your code. In other words you don't need to isolate (by using private DS) code that moves data pointers, because your whole code is already isolated.

You have simplified the discussion too far in attempting to make the point above.

The scenario I described involves:
1) Encapsulating old code that does not DEPEND on any certain state of databases and tables (no dependence on record pointer or certain tables being open)
2) Isolating that code so that what it DOES do with data does not affect anything outside of itself
3) Reusing that code at various places in the app, where the app DOES depend on its data state at that point in time remaining unchanged

I have run into countless situations in working with OPC (other people's code) where many lines of code are used in trying to save the current state of data before jumping off into a procedure or UDF, then jumping through hoops to restore things the way they were before the call.

Using the Session class in those cases to make the calls instead to code that is isolated inside its own datasession means that the state-management code can be removed, simplifying or stabilizing the app, and allowing the encapsulated code to then be reused ANYWHERE in the app without any pain whatsoever.

It's clean and simple and very useful. You may never use it, but it's there for those who can appreciate its value, particularly in refactoring or maintaining code that is less clean in its interdependencies.

Moving into the area of exposing that same encapsulated code as a COM object, Session also can provide some benefits to prevent multiple instances of the DLL from stepping on each other's data.

We could go back and forth all day, but I'm on my way right now to a client site where we're doing some encapsulating of old code are will soon be dropping in calls to our Session-based objects without breaking the app. :-)