I used to use DEs and dropped it from the reasons I outlined in my message
That is not to say that I am not using private datasession and/or n-tier architecture
The GUI itself is in form classes (and page classes)
Generic datahandling methods (Save,restore etc.) are stored in thier own classes
and all the form's business rules are stored in "form behavior" classes
The way I implemented it - I just don't have to worry about openning and closing of any view

Arnon

>Just to give a different thought..
>
>I do use the DE. All my forms are classes based off the same base class. This form has some hooks to create the DE, allow a subclass to add cursors and relations ex.(THISFORM.AddCursor(cCursorSource, cOrder, vReadOnlyorBuffMode, cAlias, cDbc) or THISFORM.AddRelation(cParent, cChild, cOrder, cExpr, cName)). This adds cursor objects and relation objects to the DE attached to the form and then calls the open data. It solves the pathing problem since i can pass in the path to the DBC(which is usaully some property somewhere).
>
>I tend to use private datasessions with small number of tables/views. This allows me to have the same form instantiated more than once with different record pointers. This also make the de responsible for opening and closing data. Another advantage i use is the fact that i can attach my DE to a CUSTOM class. This allows me to but business rules inside of custom classes and not have them dependent on data from outside source but still use the same Methodology as my forms. I also now have generic code for saving buffered data at the DE level. It loops through the cursor objects of the DE, checking buffering mode and if data is changed, and then saving.
>
>I do agree with that there is no wrong way of doing this.
>
>
>