-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/10/2010 02:55 PM, Bob Keeland wrote: > but there are cases in which the user will, in the vast majority of cases, > not have the knowledge to update the database.
None of what I wrote has *anything* to do with users. It was entirely scenarios under which the SQLite library may need to write to the database (and directory) in order to ensure consistency and durability by recovering from a separate program that may have been using the library crashing (earlier or concurrently). > 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. You seem to be confusing several things here. SQLite is a library used by *your* code. It only does what you tell it to. If you make no calls to SQLite to make changes then it won't. Users are using your program,- they can only do what your program allows. If you want to ensure that your program cannot make changes (eg you let users enter arbitrary SQL) then there is an API that is called on preparing each chunk of SQL where you can allow or deny operations: http://www.sqlite.org/c3ref/set_authorizer.html If you want to ensure code you write does not make changes then don't write any code that does so. Pretty much the only way to make changes is via SQL so you can grep your SQL queries and do things that way. (And install an authorizer as a fail-safe.) If you want to prevent the user modifying the database file in any way (eg going in separately with a text or hex editor) then you will need to use operating system access control facilities to protect from that user for the database file and the directory. You should also specify read only in the sqlite3_open_v2 call. If you want fine low level control over SQLite's interaction with the underlying operating system then the VFS layer provides that. You can implement, augment or override almost all behaviour (very little code if you inherit from an existing VFS). > This inability to have a read-only database with SQLite is unfortunate. Can you restate your problem since it isn't clear who you think is going to write to the database in the first place? Another example is some people want to ship SQLite databases on CDROM. Since the database can't be changed they also want to compress it. You can buy an extension written by the SQLite authors themselves that let you do this. It also lets you do encryption: http://www.hwaci.com/sw/sqlite/cerod.html (Alternatively if your time has no value you could code something similar yourself if that is what your needs are.) Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyyae0ACgkQmOOfHg372QRHwACgkLVkD3Y0dWw0vzLRlKk0yeGJ HQAAni99j0bjVYRbe0DsbXoPLELcESIv =crLq -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
