For a self contained database that you can run in process, SqLite is hard to beat. But it's not a database server - like FoxPro it's an ISAM db that the host application is connecting to and querying which works great for local applications that need a db, but not so great if you need to share the data file between multiple active users simultaneously.

As an alternative for standalone single access applications, these days I don't use a database but instead use a persistent data structure in memory. Just load the data into memory and write it back out when you need to save using JSON or XML. Then in .NET I can use LINQ to query the data in memory extremely quickly. One example is WebSurge (a Web testing tool) that uses memory as the database because everything else can't keep up with actual request processing :-) Querying even 20 gig of data in memory is fast (writing it out not so much though and handled with background writes). Something to think about.


+++ Rick ---


>All,
>
>We have a flagship app using C/S backend that now needs stand-alone capability- so that an auditor or other user can be sent an "extract" file on usb stick/download/email to be opened and processed on their machine without access to the customer's firewalled environment or anything else.
>
>The app uses Remote Views and SQL Passthrough so the goal is to re-use the C/S model, ideally with just a different dbc. For the standalone version there's no SP, SQL is quite standard and only one user at a time.
>
>The immediately obvious response is to use local views against dbfs for this purpose but that creates several risks, e.g. expensive support if one or more dbf/fpt/cdx files is inaccessible/missing on the user's PC for whatever reason but more importantly, dbf content has no protection. The app's subject matter is covered by privacy legislation in every market we look at, so dbfs are not viable if they're copied to external machines. Not keen to re-invent wheels or manage encryption ourselves, so we're hoping for a commercial option for what ought to be a fairly common need.
>
>SSCE and SQLite both seem to allow single-file databases with security and ODBC drivers, meaning existing C/S model can be used.
>
>SSCE seems to involve formal installation that experience suggests will be a support burden on random Windows machines of middle-aged auditors professing lack of computer expertise. However, SQLite seems to wrap all processing in the available 3rd party ODBC driver that accesses the database file directly- meaning if you can install ODBC, it should work.
>
>Does anybody have any advice or experience or better options of a lightweight database with ODBC driver, single database file and security? At this stage I'm thinking SQLite based on trawls of mostly several-year-old threads.