go to bug id or search bugs for
When opening a SQLite3 database with both the SQLITE3_OPEN_READONLY and SQLITE3_OPEN_CREATE flags, an exception thrown which reads "Unable to open database: out of memory".
While it is understandable that it doesn't make sense to combine the two flags (since creating a new database would require writing, and opening an empty database that cannot be written to is probably not very helpful), the "out of memory" error is confusing, and does not seem like an accurate description of the problem. Especially since the documentation for neither SQLite3::__construct() and SQLite3::open() hints to this, I was personally stuck for some time figuring out why it was telling me it was out of memory.
This behavior occurs regardless of whether or not the specified database file actually exists/is readable.
I propose that when either of these functions is called with SQLITE3_OPEN_READONLY, they should either silently ignore the SQLITE3_OPEN_CREATE flag if it is specified, or produce an E_NOTICE with a more helpful message, rather than throwing a fatal error with an unhelpful description ("out of memory").
$db = new SQLite3( "my_database.db", SQLITE3_OPEN_READONLY | SQLITE3_OPEN_CREATE );
Either silently ignore the SQLITE3_OPEN_CREATE flag, or throw an E_NOTICE rather than an exception.
Fatal error: Uncaught Exception: Unable to open database: out of memory in ...
Add a Patch
Add a Pull Request
Thanks for the report. As for me, the suggested solution doesn't sound optimal. It is application dependent, so why should be one flag removed in favor of another one? Another script might need it in exactly opposite way. IMO it is merely about improving the error check, not more. SQLite should be able to detect such cases.
Automatic comment on behalf of ab
Log: Fixed bug #74883 SQLite3::__construct() produces "out of memory" exception with invalid flags
The error message originate in the underlying SQLite library. I've sent a bug report to the SQLite mailing list, to see if the message can be improved.
> they should either silently ignore
No. Programs shouldn't silently discard data.
> rather than throwing a fatal error with an unhelpful description ("out of memory").
It doesn't throw an 'error'; it throws an Exception, and your code code should be catching exceptions both at the location where you're calling new SQLite3() - to catch expected error conditions, such as the database file not being open-able, and also at the top level of the application, to log all 'unexpected' exceptions that you weren't aware that could occur..
> produce an E_NOTICE with a more helpful message
No. The error message should be better, but E_NOTICES are not a good way to handle failed constructors. All constructors must either succeed or throw an exception. This was decided by RFC recently: https://wiki.php.net/rfc/internal_constructor_behaviour
After some investigation, this problem does like in the underlying SQLite library, that isn't present when compiled with an up-to-date version.
I'll open a separate issue to update SQLite.
The fix applied in this thread makes PHP7.1.8 use sqlite3_errstr. This symbol is not available in sqlite version 3.6.20, which is system default on RHEL6.
Remi's repo has a patch for this his the latest SRPM: