error changing data - attempt to write a readonly database
Hello, so I am using SQLite on a Windows Server 2012 for some time already. Now after I patched the OS and rebooted, I can't seem to edit tables via SQLiteBrowser because of this error message! Funny thing is that I can copy the .db file to another location and open it in SQLiteBrowser and it works just fine! But if I copy the file back to where it always was I get this error! This already happened to me once and I found there was a .db-journal file present, probably because I have interrupted PHP script in the middle of something. Deleting that file fixed it back then, but today there is no such file, so what's wrong and how do I fix it?
(2.1) By TripeHound on 2021-03-19 14:13:51 edited from 2.0 in reply to 1 [source]
Given that it works in one location, and not in another, including what those locations are in a problem report would be (a) helpful, and (b) (I would have hoped) obvious :-)
Best guess is the original location is somewhere that Windows (now) regards as "protected" in some measure (e.g. "
C:\Program Files") and the recent update has imposed stricter permissions on that area (or, perhaps, has removed looser permissions you might have given it in the past).
Also, it should be noted that SQLiteBrowser is a 3rd-party product. If your investigations into "protected locations" doesn't lead anywhere, try accessing the database using the SQLite CLI command-line program to eliminate anything SQLiteBrowser might be doing.
this is really weird, because it's not in some system folder. But you are right permissions seem to be a problem! It works when I run SQLiteBrowser elevated "as administrator" But I am logged on as user which is member of administrators group so that's confusing a bit... I just forgot I need to do this since I opened it last time
That's a definite diagnostic. The problem isn't in SQLite, it's part of the permissions settings of your setup.
Take a detailed look at the permissions on the folder where you keep your database files, the database file, and journal or .shm file SQLite has created, the application doing the accessing, and anything else you think might be appropriate.
For testing, create a new special local account with minimal privileges and see whether everything works.