The cause:

This error happens because the code which you are running in a path is not compatible with your definite path for the database. I have found another reason in your code:

conn = lite.connect('folder_A/my_database.db')

If you execute the code inside folder A or somewhere else that does not contain a folder A, you will get the same error. The reason is that if the database file does not exist, SQLite will creat it instead of the folder.

Solution:

You can fix your error by using a try-except expression to wrap your connection command and creating the folder if it increases sqlite3.OperationalError.

import sqlite3 as lite from os import mkdir

try:
conn = lite.connect('folder_A/my_database.db')
except lite.OperationalError:
mkdir('folder_A')
finally:
conn = lite.connect('folder_A/my_database.db')

In addition, you need to check:

1. Is the application being tested on the same machine as it is being run on?

2. Are you able to run it while it’s being tested (or have you used it with the same user)?

3. Is the /tmp directory on the disk full? (If you’re on Unix, you can find out with df /tmp).

4. Are the permissions on the /tmp/cer directory “odd”? (In order to handle things like the commit log, SQLLite must be able to generate new files).

5. Is that database still used by the unit test code? (Concurrent openings are feasible with a contemporary SQLite and the correct filesystem — however /tmp is almost always on the right kind of FS, so it’s probably not that — but it’s still not recommended).

6. Is the development code attempting to write to that database, or is something “smart” catching you off guard and leading it to attempt to open something else? (I’ve been caught out in the past by this in my code; don’t assume it won’t happen to you…).

7. Do you run your unit tests with the same SQLite version as your production code?

It’s possible that the production system doesn’t have a /tmp/cer directory if you’re not on the same machine. It is self-evident that this must be solved first. Similarly, if you’re running as several users on the same machine, you are likely to run into permissions/ownership issues. Another essential problem is a lack of disk space. I don’t believe it’s the last three, but if the more obvious deployment issues have been resolved, they’re worth reviewing. If none of the following apply, you’ve encountered an unusual situation and will need to provide considerably more information (it might even be a bug in SQLite, but knowing the developers of it, I believe that to be quite unlikely).