On 19 Jan 2011, at 8:15pm, Dustin Sallings wrote: > On Jan 19, 2011, at 11:01, Simon Slavin wrote: > >> If you do something special to keep your journal file in a different place, >> these other sqlite3 applications won't find it. So they'll just find a >> corrupt database file, and are less likely to be able to figure out how to >> restore to a COMMIT point or a SAVEPOINT. > > > I understand this concern and think it's a valid point. I can assume > for the purpose of this usage that only tools I provide will be used to > access the DB (I ship a sqlite3 binary since I'm using WAL and I've got users > on CentOS which ships sqlite 1.2 for all I know).
This solution depends on what facilities your operating system has for creating an alias, soft link, shortcut, or whatever it calls them. If your operating system does these correctly, the sqlite3 open function should correctly understand it and use it. If CentOS is just another flavour of Linux you will probably want to use soft links. Experiment with soft links (or whatever is appropriate) first, to make sure you understand what they are and how they work. Given two different filespaces ... one you want the database file on (call it D) one you want the journal file on (call it J) Step 1 ------ Set up your application to use J for both files. Start your application or whatever other tool you have to create the database file and put at least a little data in it. Quit the application. Step 2 ------ Copy your database file from J to D. Delete (or rename) the original copy of the file in J. Create an alias/link/shortcut/whatever in J, linked to the file that is now in D. Step 3 ------ Restart your application. Make sure it is correctly following the link and finding the data you have moved to D. Because your application thinks that the database file is on J, it should create the journal file on J. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
