On further research, it appears to be related to max_page_count being exceeded during insertion of a row, leaving behind a primary key reference in the (primary key) index on the BLOB instead of being cleaned up during rollback.
On 7/24/07, Andrew Finkenstadt <[EMAIL PROTECTED]> wrote:
Using 3.4.0 or 3.4.1 compiled for windows with -DMULTITHREAD, i seem to have a problem where sqlite3_step() will return SQLITE_ROW even when there are, in fact, no rows that meet the WHERE clause criteria. I'm currently attempting a reversion to 3.3.17 to see how it behaved. create table file_data ( rod blob not null primary key /* always 20 bytes long based on a collision-resistant hash function */ , file_size integer not null , compression_method integer not null , the_data blob not null ); sqlite3_prepare(..., "select file_size, compression_method from file_data where rod = ?"); sqlite3_reset(statement); sqlite3_bind_blob(...,0, ptr, len); sqlite3_step(...) sqlite3_step returned SQLITE_ROW, which was my indication that the result set would be non-empty. So I construct a query_result(statement, bool at_end=false), and then execute sqlite3_get_int64(..., first_column, null=-1) and I get back -1. Before I was passing in null=-1 I was passing in =0, which was a permissible value for file_size. ** keep in mind that my exact sqlite3_api calls might be slightly different, since I have a C++ framework that isolates me from having to continually remember the same API calls. Suffice it to say this code worked (so far as I knew) under 3.3.17. --andy
