>I'm considering this right now, it seems to be a very good approach - thank you.

You're welcome. =0)

>I'm also considering minimizing our app's SQL interaction to just look up, updates and deletes - no stored procs - so we don't get locked into one vendor's SQL

I think it's a mistake to not have Stored Procs. Look at it this way ... if you code all the SELECT, UPDATE, etc. commands in your DataAccess class, you've just locked into one flavor of SQL. Right in your app. You put it in Stored Procs instead, and you only have to worry about tweaking the procs, not your actual code. Your code shouldn't care one way or the other.

>Question: could you do your entire app without stored procs?

Absolutley not. We have no direct commands to the database ... *everything* we do is through Stored Procs.

>Where did your app get married to Microsoft SQL? In their Transact-SQL language? I can see this happening, I don't want any part of it. If I could only just be a programmer I'd be very happy.

It doesn't have to be, I suppose. We came from a background of using SQL Server, so you go with what you know. The applications that we are developing are flexible enough to handle another flavor of database anyway, so it doesn't matter. The only thing that would need to be changed is our little VFP "DBA" app, not any of our applications.

~~Bonnie