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