Sqlite3, OperationalError: unable to open database file

Question

Question: Why can\'t I open the database?

---

Info: I\'m working on a project using sqlite3 database. I wrote a test program that runs and passes it t

Answer 1

This worked for me:

conn = sqlite3.connect("C:\\users\\guest\\desktop\\example.db")

Note: Double slashes in the full path

Using python v2.7 on Win 7 enterprise and Win Xp Pro

Hope this helps someone.

Answer 2

My reason was very foolish. I had dropped the manage.py onto the terminal so it was running using the full path. And I had changed the name of the folder of the project. So now, the program was unable to find the file with the previous data and hence the error.

Make sure you restart the software in such cases.

Answer 3

Primary diagnosis: SQLite is unable to open that file for some reason.

Checking the obvious reasons why, and in approximate order that I recommend checking:

• Is the program running on the same machine as you're testing it?
• Is it running as you (or at least the same user as you're testing it as)?
• Is the disk containing /tmp full? (You're on Unix, so use df /tmp to find out.)
• Does the /tmp/cer directory have “odd” permissions? (SQLite needs to be able to create additional files in it in order to handle things like the commit log.)
• Is the unit test code still using that database? (Concurrent opens are possible with a modern-enough SQLite and when in the right filesystem — though /tmp is virtually always on the right sort of FS so it's probably not that — but it's still not recommended.)
• Is the development code really trying to write to that database, or is something “clever” catching you out and causing it to try to open something else? (I've been caught out by this in my code in the past; don't think it can't happen to you…)
• Are you using the same version of the SQLite library in the unit tests and the production code?

If you're not on the same machine, it's quite possible that the production system doesn't have a /tmp/cer directory. Obvious to fix that first. Similarly, if you're on the same machine but running as different users, you're likely to have permissions/ownership problems. Disk space is another serious gotcha, but less likely. I don't think it's the last three, but they're worth checking if the more obvious deployment problems are sorted. If it's none of the above, you've hit an exotic problem and will have to report much more info (it might even be a bug in SQLite, but knowing the developers of it, I believe that to be quite unlikely).

Answer 4

I faced the same problem on Windows 7. My database name was test and I got the error:

self.connection = Database.connect(**kwargs)
sqlite3.OperationalError: unable to open database file

I replaced test with test.db and and all went smooth.

Answer 5

For any one who has a problem with airflow linked to this issue.

In my case, I've initialized airflow in /root/airflow and run its scheduler as root. I used the run_as_user parameter to impersonate the web user while running task instances. However airflow was always failing to trigger my DAG with the following errors in logs:

sqlite3.OperationalError: unable to open database file
...
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) unable to open database file

I also found once I triggered a DAG manually, a new airflow resource directory was automatically created under /home/web. I'm not clear about this behavior, but I make it work by removing the entire airflow resources from /root, reinitializing airflow database under /home/web and running the scheduler as web under:

[root@host ~]# rm -rf airflow
[web@host ~]$ airflow initdb
[web@host ~]$ airflow scheduler -D

If you want to try this approach, I may need to backup your data before doing anything.

Answer 6

On unix I got that error when using the ~ shortcut for the user directory. Changing it to /home/user resolved the error.