This inability to have a read-only database with SQLite is unfortunate. In most cases I'll agree that a database should be something that can be updated, but there are cases in which the user will, in the vast majority of cases, not have the knowledge to update the database. A program that I am working on is mostly a 'fill the database' job for me. Writing the code will be somewhat minimal. For the user it will be a search the database for an answer that is seemingly unrelated to the database. From the user's perspective they just make selections from listed options and the number of options (selections) is reduced. What the user wants ideally is to be left with only one selection - that will be their answer. They really don't care how they get to that point. If a person updates the database they will probably make the overall program unusable. Bob Keeland
--- On Sun, 10/10/10, Roger Binns <rog...@rogerbinns.com> wrote: From: Roger Binns <rog...@rogerbinns.com> Subject: Re: [sqlite] Create Read-only Database To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> Date: Sunday, October 10, 2010, 2:04 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/10/2010 11:53 AM, Max Vlasov wrote: > Also if you're not content with this option, you can always open the file > (just as a general file) prior to sqlite with a "deny write" option. I'm > aware of such feature in Windows/Win32, I'm sure a similar option should > exist in Linux. In this case any attempt to write will lead to OS-level > error that finally will be passes as some sqlite error to your code. Actually Linux/Unix does not have such deny mode options. Additionally locking is cooperative not mandatory. There are two reasons for this. Historically Unix has always been multi-user and having the ability to deny other users/programs access to a file that they have permissions for would cause far more harm than good. The second is that system data has traditionally been stored in plain text files - things like /etc/hosts for name to IP address mappings and /etc/passwd for the user password database. If any program could deny access to those for any other program/user then it would be a trivial denial of service attack. See the Unix Hater's Guide (free PDF online) for more details of Unix locking. Going back to Joshua's original question, by default a SQLite database is not read-only even if you think it is. The major reason is that even if you wanted to use it read-only, the previous program may have had it open for writing, and may have crashed in the middle of a transaction. Consequently the reader needs to fix the database using the journal to get it back into a correct state which involves writing. Heck even while you have it open and idle, a writer could have started a transaction and crashed requiring recovery. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyyDkQACgkQmOOfHg372QQEGQCcDEK20d0jgCe1YfGLMxTT7erc 4tAAn0HBEZhM1rFpot6K+ORNTMquyZyo =iHyP -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
