The advocates of three tier architecture defend the view that applications should be unaware of how the data are physically stored. It is my understanding that this independance can be implemented through the utilization of .dbc related functions.

My first interrogation is about the level of independance that is meant: should that go as far as the conceptual schema?

First I wonder if that makes sense at all. I cannot imagine a situation where one wants to change the conceptual schema without rewriting the application.
Seconld, if one wants to encapsulate the conceptual schema in the database layer, ideally, the database should have events that fire at retrieval time. I may be wrong, but the VFP database only supports events for inserts, deletes and updates.

The alternative is the use of views with UFDs that are stored in the .DBC. But I wonder if other DBMS's wills support those UFDS, and second, that would be quite degrading in terms of performance to have all the fields evaluated through UDFS.

Now if we consider the conceptual schema to be fixed, or if we do not consider it important for it to be encapsulated in the DBMS layer, then we are free to propage SQL statements in the buziness objects. After all, that is what SQL is all about, it gives us access to the conceptual schema. We still can change physical DBMS's, at least that is the illusion I have.

The data acess tier is very thin then: it only contains objects that manage the DBMS as a resource, but it does not have to make any assumptiion about the contents of the tables and the views. It only should know how to open the database, tables and views, and maintain RI etc. . At the field level, the other tiers are allowed to 'know'

Following this strategy excludes the management of the storage of persistent data from the OO paradigm.

Hmm.

Marc