On 17 May 2010, at 9:46pm, Sam Carleton wrote: > On Mon, May 17, 2010 at 2:27 PM, Black, Michael (IS) <michael.bla...@ngc.com >> wrote: > >> Not rude -- just a communications problem... >> >> There's a difference between read-only and exclusive. >> >> Read-only just means you can't do inserts and creates. It's not the write >> mode of the database that matters. It's the transactions you run. >> read/write with insert/create might make selects and other inserts return >> BUSY. > > You left out two different types of transactions: update and delete. > Obviously delete is on par with an insert, so that is a no brainer, but what > about update's? Can a read-only DB do an update?
No: an UPDATE command exists to make changes to the database. That would require read/write permission not read-only. > By my definition that > would be a writing operation, but is it seen differently with SQLite? You got it correct. > I > could see how updating a row might be less invasive because it very well > could mean that a few bits are being changed. On the other hand, if it is a > varchar, then it is variable length, which still leads me to believe that > updates are not possible with a read-only connection. The problem is not to do with variable lengths. Any form of writing at all, even if it's just replacing one INTEGER with another, requires a whole level of locking to be implemented while the changes are being made, if only to prevent you from getting changes half was through a COMMIT. For instance, if one UPDATE command changes two fields of a single row, you can't risk letting a SELECT happen half way through the operation. This is one of the things the read/write mode prevents. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
