Tony,

>From reading one of your articles at http://portal.dfpug.de/dFPUG/Dokumente/Konferenzen/VFP-Konferenz%202002/55_E-NET4.pdf, it seems to me that your architecture is contrasting that of Microsoft for example IBuySpy portal.
>Your BusinessObject contains a table name, a field list, GetDataSet() methods so database access mechanism is contained within the business object itself. Microsoft has two sepate objects, a business object that calls a corresponding database object that accesses database for it. I would imagine that with a true n-tier architecture, business objects should not know any thing about the database (i, e. table name and query string). What are your thoughts on this?

DotNetDave's answer was on the money...we do have a separate data access layer for our business objects that contains the data-specific code. You're right in that you don't want data-specific logic in the business object.

The business object table name property only specifies a default name to give the DataTable within a DataSet and does not necessarily correspond to a back end table...you could pull from two different back end tables and place them in a single ADO.NET data table.

Regarding query strings, although most developers choose to put them in the business object itself (MM .NET data access classes do some data-specific translation of query strings that are passed to them), you can also choose to put them in the data access class, or for that matter, in stored procedures.

Regards,