>Yes Craig,
>
>Life is full of trade offs. I suppose the company that brought into a backend server could rewirte the application if it ever needed to migrate to something new. If a heavy investment has been made in Store Procedure, such that a significant part of the application existed in the database itself, it might detour a Company from considering any other database execept in the extreme circumstance when no other choice exited. There are always many consideration, and I feel like everyone does the very best they can. Nothing is certain.
>
>LelandJ

Alot of people feel that THE way to create database applications is to have ZERO client side or client generated SQL, and do ALL data access via SP's. This way, a conversion to another database is just a matter of duplicating the database API (sp's) on that new database.

Some people feel this is the EXACT WRONG way to do it. They say that generic SQL should be used so all databases can be used without changing any code.

Some feel (see Scott Amblers) web site... that there should be ZERO sql code written and that a persistence layer should be created that allows mapping relational data bases to objects so that your code is more oop. Targeting a new database just requires that the persistence layer know how to generate SQL compatible with the database in question.

***************
Of course, with VFP we have another option. Remote views. A new DBC is created for each back end which would allow for backend specific SQL to be used for each database, without changing the API to the data or the client code.

************
Personally, I have only so far used the remote views method, having stored procedures for data intensive processes. Although I have wanted to create a persistence layer for VFP for sometime now, I just seem to keep getting sidetracked.

BOb