Quoting Nuno Lucas <[EMAIL PROTECTED]>: > You probably want to look at the "empty_result_callbacks" PRAGMA. > Although the manual only mention sqlite3_exec, it's also used by > sqlite3_get_table(). >
This looks like what we need. I assume that sqlite3_get_table() returns the correct number of columns instead of 0 in our case if this PRAGMA is toggled on. > Note that you will need to change your code to handle the extra "row" > with the column names. > This code is already in place as we use this extra row in those queries which do return at least one row of data. > Any way, you will be better off using prepared statements. > sqlite3_get_table is maintained for compatibility with really old code > (there isn't a Unicode equivalent, for example). > The preferred interface is using the sqlite3_prepare_v2() and related API. > sqlite3_get_table() is just a wrapper around the "modern" interface. > I wouldn't mind using prepared statements. However, libdbi keeps the results of queries ready for accessor functions which later read single rows of data. That is, to create a libdbi result set, we have to loop over all returned rows anyway and create an array of strings. Doing this ourselves in the driver would simply duplicate sqlite3_get_table() in a probably less tested fashion. How did other users switch from the old to the new interface? Does everyone build a string array from the callbacks himself these days, or did I miss some simple and obvious way to switch? regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
