Repository navigation
Conversation
Setting save points does not make sense for read-only databases, so do never set a save-point while executing a user query if the database has been opened in read-only mode. If setSavePoint is ever called in read-only mode, a warning is printed and the save-point is not set. If ever a read-write query is executed, it would be rejected by SQLite so there is no risk of immediately committing any change to the DB.
|
Hmm, looking at this and at #1543 I'm thinking it might be easier to just not do any checks at all (also because there might be more problematic spots in the future, like we could enable the Edit Table dialog in read-only mode and allow creation of temporary tables via it) and just modify |
|
Maybe, but we would also have to address the enabling of the save and revert buttons and maybe other issues. Not sure what approach would be better. #1543 is also for not raising spurious save/revert buttons, but that one would also apply to read-write databases. |
72e8daf to
e392e64
Compare
|
I have just merged this 😄 I don't really remember what I thought about this back then, but let's just try it 😉 |
Setting save points does not make sense for read-only databases, so
do never set a save-point while executing a user query if the database has
been opened in read-only mode.
If setSavePoint is ever called in read-only mode, a warning is printed and
the save-point is not set.
If ever a read-write query is executed, it would be rejected by SQLite so
there is no risk of immediately committing any change to the DB.