Bad SQL x bad RDBMS behavior

ferreira on 2005-10-21T22:49:07

Well, as in any programming language, one occasionally makes some (or many) errors. And then the parser/compiler tells you missed the point and preferrably what you made wrong. SQL databases are among the worst language interpreters with their error messages. The longer your SQL the harder to get where is that damned error. I fed

SELECT 'a


to DBD::SQLite by mistake, only to discover that it doesn't emit an error. It passes and the answer is a result set with one row with 'aa'. This is not a DBD::SQLite issue, it is a SQLite issue that survives until the current version 3.2.7. Well, I submitted a patch to them and, in the next release, I will be surprised with "unterminated string" which is understandable (or not).


SQLite doesn't choke anymore on unclosed strings

ferreira on 2005-10-25T11:00:51

For the record, drh accepted the patch (brutely simplified) so that SQLite now handles correctly unterminated strings. It is in CVS already. I wait for the next release, 3.2.8 or so.

Now it is for real

ferreira on 2006-09-10T16:39:11

If you try DBD-SQLite-1.13 (with SQLite 3.3.5 sources), you will see that the issue with unterminated strings is over. You will get an error message like this:

DBD::SQLite::db prepare failed: unrecognized token: "'eek"(1)

But it never was a fault of DBD::SQLite but a problem of SQLite. I am not sure if the first correction by drh missed something or if the fix only got to the sources much later. But the point is that it is just right now.