We have recently had a lot of success using an n-tier design. Like Kisner & Co., we have a UI tier, a business objects tier, and a data-services tier. All of our SQL statements are completely contained in the data-services tier; even our WHERE clauses are generated in this tier based on values passed by the business objects. All of our data transmitted between the data-services tier and the business objects tier is in the form of a single string that is a direct memory copy of a user-defined type (differing for each object). By keeping these two tiers completely separated we can switch to a different database and only have to make changes to the data-services tier. This is one of the many advantages of an n-tier approach: as long as all objects maintain their interface, the business objects don't care how the data-services objects get their data from the database. Theoretically, there should be no reason why you cannot use Oracle, SQL Server, Access, or any standard DBMS.<br>
<br>
We don’t use any stored procedures. In the data-services tier, we use ADO just as we would in any normal application. The difference is that this tier is only responsible for receiving requests from the business objects, getting the appropriate data from the database, and returning that data to the business objects in the requested form. Of course, the data-services tier is also responsible for all other forms of persistence – saving, deleting, creating, etc. The business objects tier is where you apply all business rules and enforce type checking. This makes the UI a very thin client. It creates objects and calls their methods, but all of the DB processing is between the application server and the database server.<br>
<br>
I hope this makes sense and helps answer some of your questions.<br>
T<br>