-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Description
Details for the issue
What did you do?
Open a DB Read only.
In Execute SQL tab, execute
create temp view foo as select * from table1;
File => Close DB
What did you expect to see?
Nothing
What did you see instead?
? Do you want to save the changes made to the database file ...?
While it is reasonable not to parse all the commands & responses in an "Execute" tab to determine if actions modify the database, it is guaranteed (I hope) that a database open as Read-Only can not be modified!
So, Option 1: Don't pay attention to the "Dirty" flag if a DB is open read-only,
However, it appears that you may be able to use SQLite to detect a modified DB fairly painlessly.
Option 2: Section 1.3.6 of the DB header spec says:
The file change counter is a 4-byte big-endian integer at offset 24 that is incremented whenever the database file is unlocked after having been modified. When two or more processes are reading the same database file, each process can detect database changes from other processes by monitoring the change counter. A process will normally want to flush its database page cache when another process modified the database, since the cache has become stale. The file change counter facilitates this.
In WAL mode, changes to the database are detected using the wal-index and so the change counter is not needed. Hence, the change counter might not be incremented on each transaction in WAL mode.
So unless the DB is in WAL mode, you can rely on it instead of your own dirty bit. (The API indicates that sqlite_file_control(SQLITE_FCNTL_FILE_POINTER) returns a pointer to sqlite3_file object, which includes a pointer to a sqlite3_io_methods object, which should allow you to xRead the header) There should be an API to access this directly, but a quick scan of the documentation didn't turn it up.
If this works as expected, you would not have to maintain your own "dirty" flag for R/W databases either. I would expect that to simplify your code, even if you have to save/restore the journaling mode to avoid WAL.
Useful extra information
The info below often helps, please fill it out if you're able to. :)
What operating system are you using?
- Windows: ( version: 10 pro___ )
- Linux: ( distro: ___ )
- Mac OS: ( version: ___ )
- Other: ___
What is your DB4S version?
- 3.10.1
- 3.10.0
- 3.9.1
- Other: ___Aug 23 nightly
Did you also
- Try out the latest nightly version: https://github.com/sqlitebrowser/sqlitebrowser#nightly-builds
- Search for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20