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.



>>Good question - its in 7 tables now, which with indexes is 14 files. I was hoping I could just ship it with one database file for easier installation issues.
>
>Having a native engine that is flexible as FoxPro's is a much better choice than trying through some sort of interop to get to sqlLite or even Sql Compact is not even a contest in my opinion. Part of the reason you're using VFP I'd hope is BECCAUSE of the native data engine.
>
>Stick the files into a seperate folder to minimize the impact of file pollution and call it a day - you'll be much happier in the long run using native tables for a small app than anything that'll require remote commands or ODBC. Plus you probably have to install DB drivers on install machines...
>
>+++ Rick ---
>
>
>>
>>
>>>>Anyone have any experience using VFP and sqlite? I have a small app (7 tables), and something bigger than sqlite seems like overkill.
>>>>
>>>>If so, suggestions would be appreciated.
>>>
>>>Then why not VFP Native DB?