Hi, Daniel,
Regarding:
"Another morning another question, what sort of facilities does
SQLite provide for Loading from a read only storage location and then
saving changes to a separate read/write storage unit? I know I can open
a database file with a read only flag but how would I go about managing
the changes to that database and storing them to a separate storage
device? All I could think of is creating a separate read/write database
on the read/write storage but short of duplicating tables between the
two databases I can't think of a simple mechanism for organising the two
tables so only the changes to the original read only table are stored
out into the read/write table with out adding allot of data management
logic on the code side."
"I'd imagine there is some mechanism for dealing with this kind of
storage layout if SQLite is used in embedded systems as the sort of
storage arrangement I'm describing is fairly common but I'm unsure as to
the terms to search in the documentation for as every product seems to
use different terms for that sort of facility. Any help or pointers to
the correct bit of documentation to look at would be most appreciated!"
=============================
I may not be understanding your questions well, but as to:
"...without adding a lot of data management logic on the code side."
SQLite's goal (I believe) was to deliver a very small, lightweight SQL
engine implenting most of the SQL-92 standard. From that viewpoint,
tasks such as:
-- synchronizing two databases or
-- presenting a unified view of a datastore split between a read-only
database and a read-write one
fall squarely outside of the sqlite library. Of course, someone on this
list may possibly have written such code and may be willing to share
tome tips, though I don't personally recall any discussion on a
read-only / read-write split.
Sqlite *does* implement a very useful ATTACH command so that you can
work on multiple sqlite databases, though.
If you *do* develop a code layer you think would be generally useful,
you may want to share it in the CONTRIBUTIONS section of the website.
Best of luck,
Donald Griggs
This email and any attachments have been scanned for known viruses using
multiple scanners. We believe that this email and any attachments are virus
free, however the recipient must take full responsibility for virus checking.
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the named recipient of this
email please notify us immediately and do not copy it or use it for any
purpose, nor disclose its contents to any other person.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
