Repository navigation
Modifying table structure of a read-only database doesn't fail with an error #974
Description
Details for the issue
If you open a read-only database, adding a new record correctly fails.
However, if you modify the table structure, pressing 'Write Changes' generates no error, so the user may incorrectly assume the modification was successful.
Closing and re-opening the database confirms the modifications were not successful. In fact, after clicking OK, the table refresh does not show the new fields, so you don't have to close the database.
http://screencast-o-matic.com/watch/cbe1jl6ug4
Just to confirm. The database was saved in c:\program files (x86), so no temp files / journals, etc could be written*. This is slightly different to the database having the 'read only' flags set.
(* If DB4S was started with admin permissions, the above error wouldn't have occurred.)
Useful extra information
I'm opening this issue because:
- DB4S is crashing
- DB4S has a bug
- DB4S needs a feature
- DB4S has another problem
I'm using DB4S on:
- Windows: ( _version:_10 (x64) ___ )
- Linux: ( distro: ___ )
- Mac OS: ( version: ___ )
- Other: ___
I'm using DB4S version:
- 3.9.1
- 3.9.0
- Other: ___
I have also:
- Tried out the nightly version: https://github.com/sqlitebrowser/sqlitebrowser#windows
- Searched for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20
- Cried myself to sleep
Activity
[-]Modifying a read-only database doesn't fail with an error[/-][+]Modifying table structure of a read-only database doesn't fail with an error[/+]justinclift commentedon Mar 6, 2017
Oh wow, good catch. That's definitely a bug needing fixing. 😄
chrisjlocke commentedon Mar 6, 2017
Not sure how the above first error gets detected .... I presume as writing to the journal fails.
Presume creating a temp file at database opening and trying to write to that would 'test' if the database is writable. It wouldn't solve the actual 'database attributes are read-only' though... unless that could be identified... so a two-part test would be needed.
justinclift commentedon Mar 6, 2017
SQLite itself provides a function for opening databases in "Read only" mode. Enforced by SQLite itself.
From memory, we use that function to open the database when we detect it's not writable. eg file/dir/etc permissions blocking it
Watching your video, I'm thinking the "Modify X" (table/index/etc) option shouldn't be enabled when the database is in read only mode, and things are going pear shaped from there. 😉
MKleusberg commentedon Mar 23, 2017
Hmm, are you sure you tried this using the latest nightly build? 😃 Because for me the 'Modify table' option isn't even enabled. Also, can you try opening the file using the
File -> Open database read onlymenu option to see if that makes any difference?chrisjlocke commentedon Mar 23, 2017
It wasn't the latest nightly at the time, as there was a cough few technical issues with the nightly production system...
Will try the latest nightly and check. 👍
justinclift commentedon Mar 23, 2017
Yeah, the (home grade) network switch the build mac is plugged into was acting weird. It was stopping the box from picking up a network connection after coming out of sleep mode.
In theory (!), it should be fixed now.
MKleusberg commentedon May 1, 2017
Any updates on this? 😃
chrisjlocke commentedon May 2, 2017
Yes, sorry for the delay. Just tested the latest nightly, and opening the database in a read-only location correctly correctly disables the necessary buttons, so modification isn't possible.
Testing this issue reminded me that after installation of the nightly, DB4S is run with 'god' permissions (at least on Windows) as the installer also has 'god' permissions, so runs DB4S under the same authority (see #338). Testing the above initially 'failed' as DB4S could correctly write to c:\program files (x86)\ which a normal user wouldn't be able to do.
justinclift commentedon May 2, 2017
Thanks @chrisjlocke, that's excellent. 😄
With the god mode problem, should we drop the offer to run DB4S from the last page of the installer? From memory that's controllable by an option in the CMakeLists.txt file. Thinking about this more, we'd probably want to ask about this on the CMake and/or NSIS mailing lists too. We're probably not the only ones with the same problem.
chrisjlocke commentedon May 2, 2017
This might help.
http://stackoverflow.com/questions/16555625/how-to-launch-an-executable-on-the-end-of-installation-correctly
justinclift commentedon May 2, 2017
Oh wow. That should do the trick. We probably can't change the way it's called directly ourselves, but if we report this to the CMake people along with the solution then it's possible that approach will be incorporated there instead.
I'll add get that done this week, so there's some good lead time for a new CMake release to come out (etc).
justinclift commentedon May 2, 2017
Hmmm, the problem with CPACK_NSIS_MUI_FINISHPAGE_RUN is that it only takes one argument.
But if we install a batch file to do the launching, that limitation might go away. eg something like: