We use SQLite for persistence of our project meta-data (the data itself is still in a proprietary binary format). For now, on project load, the meta-data DB file is read in full into memory (C++ objects) then closed, and re-written from scratch on save or save-as, instead of trying to update it in place.
When loading an older project, we need to upgrade (within a transaction) the meta-data DB to the schema version understood by the current application, load the upgraded DB, then rollback the DB file, to leave the original project untouched. That's working fine, except when the user opening the project has read-only access to the DB-file (case#1) or even to the directory the DB file is in (case#2). We run in normal-mode, not wal-mode, i.e. SQLite creates a journal file on the upgrade, and possibly also changes the .db itself (to record the ongoing transaction? I don't know). But in the read-only cases described above, the upgrade fails, and the user thus cannot open the project. My question is then whether there's a way to perform the to-be-rolled-back upgrade in such a way to not run afoul of the read-only file/dir permissions? We can of course copy the db file somewhere else with r/w access, or copy the DB into an in-memory DB (for each table, create table memdb.foo as select * from dskdb.foo) and upgrade and read that one instead, but I was wondering whether there's another better solution we could use? Thanks, --DD _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
