Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ferreira (5993)

  (email not shown publicly)

Just another Brazilian Perl hacker.

Journal of ferreira (5993)

Friday October 21, 2005
05:49 PM

Bad SQL x bad RDBMS behavior

[ #27277 ]
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


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).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.
    • 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.