>Without relighting this old debate (which has no winner, no matter what you might think :-), search the subject for this thread jsut a few weeks ago):

Didn't know there was one - haven't been around much lately. It's not a matter of winners or losers - just alternatives and preferences.

>Just because a form doesn't have a DE doesn't mean it can't have a private datasession.

Thought that was my point in the first place.

>Huh? Datasession has absolutely nothing to do with object scope. Setting a datasession does nothing to expose objects or PEMs, only cursors.

I guess I didn't phrase it properly:

You can build an entire DataEnvironment (via Aggregation) around a session class. Not only can the session class have custom PEMs, but a DataEnvironment object can be attached to it (also having custom PEMs) which can contain cursor objects which also have their own custom PEMs - not to mention a SessionSets object for all those pesky SET Commands. Furthermore (and most important), their abstract methods can be designed to hook methods in a visual class object, thus alleviating the need to subclass the PRG DEFINEs.

So with this design, all you need is a reference to the session object. The DataSessionID merely exposes the cursors to the form and it's controls as you have stated.

I know you know all of this. My purpose is not to debate you or anyone, but just to offer alternatives to those who may be interested.