Hi George,

>Final thought, I've always thought that having the DE as a member (technically) of the form was backwards. When I see "member" I tend to think in terms of "child" for the DE and "parent" for the form. I think of the data using the form to display itself and get input. It just seems that the way it is, the form uses the data. If we really encapsulated the data, then everything it need to manage itself (load, save changes, etc.) would be with the data, and the form would merely be an I/O device. Granted some of this functionality is already present, much of it isn't.

I agree with you and I think it is the way the help file or documents which establish the relationship of the form and DE which is wrong (in a way).

Taking an example users would never think of a form to have multiple DataEnvironments for a form.... Probably because their minds are tuned that way. Why would we need such a functionality is just a matter of design and encapsulation.

The form uses all the DataEnvironments available for a private datasession. The CodeBook for e.g. uses a DataEnvironment for each business object and multiple business objects are dropped on the form. Which means that there are multiple DE's in the background. The form here is just a place for displaying information... like you said.

BTW, I am not promoting CodeBook here but it is just an example which I think was easy to explain. :-)