BEGIN IMMEDIATE fails when there is a read-only database attached. I'm not saying this is a bug, but it is unexpected behavior and at least mildly inconvenient. Consider the situation where I've opened one database read-write and attach another read-only:
sqlite> attach database 'file:ex.db?mode=ro' as ex; sqlite> begin immediate; Error: attempt to write a readonly database Now, it's not like I *could* modify anything in ex.db anyway, so there's no need to try to lock it (and it's not like SQLite doesn't know it's a read-only database), but since I know I'm going to be writing to the main database, it'd be nice if I could grab it and lock it now before I hit my writing code, as this makes my error handling a bit simpler. Anyway, the behavior *is* documented on the BEGIN TRANSACTION page: "If the transaction is immediate, then RESERVED locks are acquired on all databases as soon as the BEGIN command is executed, without waiting for the database to be used." But reserved locks are defined like so: "A RESERVED lock means that the process is planning on writing to the database file at some point in the future but that it is currently just reading from the file." And since you can't write to a read-only database, why try to get a reserved lock on it in the first place? Best regards, Peter _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
