I've got three options, two of which require an internet connection, one
part time, the other full time.  The third option has the constraint on the
size of the data in question.

- Have your preference of a resultant hash check in a plain text file
sitting somewhere on your web server.  The application pokes the server at
each run to verify the hash against the physical hash of the DB.  If a
missmatch is found, force a download.  This will make sure your end users
have the most up to date data, as well as protect your primary criteria of
keeping the data 'read-only' at application run, however, an internet
connection would be required at least for the initial check.

- Have your application query a database on your server via web or socket
protocols instead of relying on the flat file.  This becomes bandwidth
heavy, and the end user machine requires an internet connection for the
life of your applications running lifespan on the client computer

- If on Windows (I'm not sure if other OS compilers have the capabilities)
Build the database into your software via a resource file.
-- Depending on the IDE, you can have the compiler automatically create a
resource file that'll be put directly into your compiled code, and it'll
build that resource file on a full build, or, on an if-needed basis.
-- Run an MD5 (Or whatever your pref is) against the physical file being
built into the EXE
-- At run time, if the database doesn't exist or if the MD5 check fails,
dump the resource file back out to the physical file.
- The downside of this is that you'll be retransmitting the application
each time, BUT, it'll guarantee that your data is consistent based on the
build of your application.
- Implementation of the checks and balances would be new code, but, only
need to be built for the applications startup.  Once the physical file is
placed down and is valid, your existing routines will work (Provided you're
closing the DB properly, writing out the database file, then re-opening the
database against the same variables)
sqlite-users mailing list

Reply via email to