Reading the API documentation is not an easy way to switch from v2 to v3... Changelog is better in fact: The sqlite3_step() interface returns SQLITE_BUSY if it is unable to commit a change because of a lock.
Now i get the v3 full speed with a tiny call to my busy callback in threaded environment. that's great. The legacy sqlite3_exec should be modified to call by itself the busy callback after sqlite3_step in case of RESERVED lock. This could simplify greatly the migration between v2 and v3. API documentation reference is wrong in sqlite3_step: "SQLITE_BUSY means that the database engine attempted to open a locked database and there is no busy callback registered. Call sqlite3_step() again to retry the open." For now, with a busy callback registered, SQLITE_BUSY can returned by sqlite3_step without calling the callback at anytime... this should be detailed. Quite nothing... SQLite v3 definitively rocks! -- Guillaume FOUGNIES
