[Simon Slavin] > The solution I came up with is that the database file owner also > uses Apache to look at it: I use web-facing database administration > software rather than opening the database in another application. > (I wrote a simple one myself in PHP and JavaScript.) However this > is unacceptable for some users.
That gave me an idea, which should solve the problem for me. Only two applications access the database: apache or the sqlite3 commandline tool. So I simply chowned the sqlite3 application and made it setuid apache. It doesn't solve the general case, though, where any application owned by any user in a certain group should be able to access the database. > You're using WAL mode. DELETE mode is the default behaviour: when > the last connection to the database is closed, the journal is > deleted. But you can change this to TRUNCATE or some other value > that suits you. That way, the files will not have to be remade. So > then you would … I chose WAL since I'd like to have as much concurrency as possible. If TRUNCATE means that the files will always be present, never deleted, then I suppose that also could solve my problem, since the file then could be made group writeable. Any reason why sqlite doesn't use the same file permissions as the database file when creating these extra files? -- Steinar _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
