On 1/5/17, Jens Alfke <j...@mooseyard.com> wrote: > > That would explain the SQLITE_BUSY error — if the pragma returns a non-empty > list of rows, and you’re not reading the rows or resetting the statement, > the statement stays busy and will block closing the database. >
There has been a change in behavior of the sqlite3_column_count() interface. The behavior change was caused by the new pragma table-valued functions. For columns that return no rows, sqlite3_column_count() is sometimes now returning a different number of columns than it used to. This should be of no consequence, since zero rows times N columns is still zero regardless of the value of N. If you check the documentation, it says "This routine returns 0 if pStmt is an SQL statement that does not return data (for example an UPDATE)." Th3 sqlite3_column_count() interface is intended to tell you how many columns are in the result set. It was never intended to tell you whether or not there is a result set. I put in that sentence about "returns 0" many many years ago. I had completely forgotten about it. But apparently, many people are looking at the result of sqlite3_column_count() and if it is zero, they never bother to sqlite3_finalize() their PRAGMA statements. Or something. In other words, they are using sqlite3_column_count() as an indicator about whether or not the statement has content to return. The idea sqlite3_column_count() could be used to determine if the statement returns anything has never been true. "SELECT * FROM table WHERE 0" never returns any rows, but it will still give a non-zero column count. The column count is determined when the SQL is compiled into bytecode, but we often do not know if the number of rows will be zero until after the bytecode starts to execute. We are trying to get the 3.16.2 patch release out the door to fix the serious blunder described by https://www.sqlite.org/src/info/30027b613b4 but now I'm thinking we need to go back and make sure sqlite3_column_count() always returns *exactly* the same value as it did in 3.15.2, regardless of how inconsistent that value might have been, so as not to break applications that were using sqlite3_column_count() in unintended ways. That means delaying 3.16.2 until next week sometime. Maybe I should rollback the website to 3.15.2 temporarily until we can get 3.16.2 ready... -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
