I keep my business objects(Session, DataSession, Cursors, etc.) completely separate from the UI (forms in this case). And since I only use form classes there is no DataEnvironment to contend with, only the DataSessionID.

When a form is instantiated, the form's DataSessionID is set to that of it's BizObject in the form's Load Event - here, SET DATASESSION is not neccessary.

However, I can swap BizObjects at runtime (changing the form's DataSessionID) all day long via a custom method of the form class - here, SET DATASESSION is neccessary. This method calls another abstract method which can and does rebind any controls if neccessary. Note that I said if neccesaary because it depends on how the controls are bound at design time.

While you may not agree, I use this design flawlessly in development. Also, while the need to swap BizObjects at runtime is infrequent, it does come in handy in certain situations.

This is a good example of implementing OOP and object reusability.


>My opinion is that it's ok to set a datasession as long as you never have to set it back. I agree with Chuck that it's better not to have to set it and if you can architect the system to avoid changing the datasession, you are better off.
> The main problem with setting a datasession is that if any controls are bound to data in the former datasession, they will become completely lost (ie detached from the data) and there is no way to rebind them.