As you probably know, the sqlite3_step() interface is used to step through the results of an SQLite query. The sqlite3_step() function returns SQLITE_ROW for every row that is returned, then SQLITE_DONE when there are no more result rows. After SQLITE_DONE (or an error) is returned, one can use sqlite3_reset() to rewind the statement back to the beginning then start calling sqlite3_step() again.
Prior to 3.6.23.1, if you called sqlite3_step() after it returned SQLITE_DONE and without first calling sqlite3_reset(), you would get an SQLITE_MISUSE error. But, we were told, this was causing problems for some poorly coded applications that were getting back SQLITE_BUSY or SQLITE_LOCKED and were immediately retrying sqlite3_step() without the intervening sqlite3_reset(). Rather than force a huge cloud of (mostly smartphone) apps to be fixed, we decided to change the way sqlite3_step() worked so that if you called sqlite3_step() again after an error or an SQLITE_DONE it would reset automatically instead of returning SQLITE_MISUSE. But now it seems, that this 3.6.23.1 change is causing problems with a different set of poorly (read: incorrectly) coded (smartphone) applications. We are told that there are many apps that terminate their loop upon receiving SQLITE_MISUSE rather than SQLITE_DONE. When those applications are linked against newer versions of SQLite, their loops spin forever since the sqlite3_step() now resets automatically and never returns SQLITE_MISUSE. The proposed solution is to modify the behavior of sqlite3_step() yet again so that it only automatically resets after returning either the SQLITE_BUSY or SQLITE_LOCKED error. Any call to sqlite3_step() after returning SQLITE_DONE or some error other than BUSY or LOCKED will revert generating an SQLITE_MISUSE, just as it did for all versions of SQLite prior to 3.6.23.1. This is, technically, a compatibility break. On the other hand, there appear to be vast numbers of smartphone applications that currently depend on undefined behavior and will suddenly stop working if we don't make this change. So the question to you, gentle reader, is should we make this change, and break backwards compatibility, albeit in a very obscure way, or should we be hard-nosed and force hundreds or perhaps thousands of smartphone application developers fix their programs? -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
