I just ran into a possible bug when trying to add some debugging ability to my
app. I have a global #define for the max # of bindable columns (to tweak for
perf/statement cache/etc.), and I wanted to make it so I could set it to 0 to
basically disable my statement preparation code, so that I could debug queries
with actual values instead of useless bound parameters ("SELECT * FROM Table
WHERE Id = ?1" isn't terribly useful in a log file). One side effect of making
this change is that, on connection, my code attempts to call:
sqlite3_limit(_handle, SQLITE_LIMIT_VARIABLE_NUMBER, MAX_PREPARED_BIND_COLS);
When I send in 0 for the MAX_PREPARED_BIND_COLS, the sqlite3_limit call returns
the old value of the DB (32767), implying that the set failed (which should be
fine - my code still won't bind any columns). However, a few dozen queries
later, my init code then attempts to insert into an FTS table with a very
simple insert ("INSERT INTO Table(docid,Keywords) VALUES (8,'test')"), which
immediately errors with SQLITE_ERROR, with the useless detail text of "SQL
logic error or missing database". If I simply comment out the (seemingly
no-op) sqlite3_limit call, then everything works as normal, and I'm not binding
any parameters (verified as such).
Is this a bug somewhere deep inside SQLite, or am I missing something? :) I've
worked around it simply by not performing the _limit call if the number is 0,
which is fine, but this seemed like it might be exposing something bad you guys
might know more about...
Thanks!
-David
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
