Thanks for your explanation. This approach seems to be good indeed.

What about the field values. When I have a view "PersonInfo" and the class "Person" opens this view: Another object now wants to retrieve the name of the person ("PersName"): should this be a property on the class, or a method that returns the view's field value?

What I did so far is not to use a view at all: The Person class selects the information from the table (SQL statement), stores all field values into properties and closes the table (optionally). For the editing and retrieving of the data I just refer to the properties of this object. When data has changed and must be saved, the procedure would be: Open table (or view), locate the record ID, write properties to the fields of the table or view.

Does this make sense?

>Christian,
>
>You could use views as the data source that is controlled simply by a data object.
>
>all the data object would do is to open and update the views needed for the forms that are being opened. This is the approach i use and seems to work for all situations i have come across so far. even if going client-server just replace the local with remote views. i usually have a table which holds the name of the local and remote views and a third column which is the alias for the view, which means all that is needed is a flag to say if the application is local or remote or a combination of the two.
>
>The business objects should provide the business logic, ie validation, how objects are displayed etc. the data object i create sits below the business object and passes the view name to the business object, from there the business object controls what information is kept where. you can control source the objects on the form because they will be controlsourced to views, it does not matter if they are ADO, SQL-server or oracle.
>
>I hope this helps