>There is always SQL Server Express Edition that can be used too.
>
>I see your point rick about using the native VFP tables - obviously it would make the install a bit easier to put together - but consider this:
>He can use remote views to connect to his VFP database via ODBC
>The ODBC driver specs are nothing other than registry entries so those can be included in the install.
>If he later wants to change to mySQL, SQL Server, Oracle, or whatever - then all he has to do is create the tables in the new backend and point the connection string in his VFP remote views to point to the new database.
>At the outset it seems weird because you're using remote views to connect to a VFP database - but in the long run this idea works really really REALLY well because it makes changing the backend database a 2 minute deal. I've been doing this for years and surprised I haven't got more folks out here to try it.

If all you're doing is just CRUD with fields as they are, then no problem. But if you start more complicated stuff, like having native functions or expressions in your SQL statements, guess what - the differences between dialects of SQL will make your code really ugly, and you'll have lots of places in your code where you need to write the same SQL statements in as many versions as db engines you support. And you still have to keep versions of your views, so it's not like you have one view per table and tell it at opening time from which db you want to pull the data.