>That's correct. But if you tell them, "It has been optimized to use SQL Server", most companies will still buy it, even if they are an Oracle shop.
>
>Another option, but one that takes more work and more maintenance, is to develop back end specific code to support multiple databases. In this scenario, all data access goes through a class that's written specifically for the back end you are using. If you do it with Interfaces, your application won't even know the difference.

I started to do that once and backed out of it 1/2 though. What I've done in the past is be reaaaaly really careful how I design the tables and database - then use remote views for everything. If all is designed properly, switching between different backends (VFP, Oracle, mySQL, SQL Server) it as easy as changing one connection string. Tricky things to watch for - date, datetime, and boolen fields...and I also avoided stored procedures.

>>If I develop an specific app to a specific client, that uses in his/her company a specific SQL software, I can use all of that engine's capabilities, which is good, but if develop an app that can be used by diferent clients, and each of them uses diferent SQL software, think that's the aproach I should use, otherwise won't be able to sell the product to clients that use other SQL software than that I used (in its full capabilities) to develop the app. Think that's the price I have to pay.
>>
>>The point is: people (at least here in Brazil) don't want to hear that an application is developed using DBFs, but if It is a Client/Server app (using SQL Server, Oracle, MySQL etc) they "tend" to change their mind (even if the front end is a VFP app).