Well, yes sure. I would always prefer using SQL Server for applications. Overall it's just a more reliable environment and it's easier to debug and manage. But for small apps with a few tables SQL Server is complete overkill. And SqlCE (as Craig mentioned) doesn't appear to have ODBC drivers so you'd be stuck with ADO (yuk).

FWIW, I've been doing cross database access for years without using remote views, using wwSQL, which wrappers SQL Passthrough, ADO, or direct VFP table access. You have to be careful with SQL Syntax to stick with ANSI SQL but this is also true for remote views I guess. It's definitely useful to have an upsizing option in the future - many apps I've created never looked like they'd need it but in the end ended up going to some sort of SQL backend. :-)

+++ Rick ---

>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?