Evaluate An sql Statement

int sqlite3_step(sqlite3_stmt*);

After aprepared statementhas been prepared using eithersqlite3_prepare_v2()orsqlite3_prepare16_v2()or one of the legacy interfacessqlite3_prepare()orsqlite3_prepare16(),this function must be called one or more times to evaluate the statement.

The details of the behavior of the sqlite3_step() interface depend on whether the statement was prepared using the newer "v2" interfacesqlite3_prepare_v2()andsqlite3_prepare16_v2()or the older legacy interfacesqlite3_prepare()andsqlite3_prepare16(). The use of the new "v2" interface is recommended for new applications but the legacy interface will continue to be supported.

In the legacy interface,the return value will be eitherSQLITE_BUSY,SQLITE_DONE,100)" rel="nofollow" target="_blank">sqlITE_ROW,100)" rel="nofollow" target="_blank">sqlITE_ERROR,orSQLITE_MISUSE. With the "v2" interface,any of the otherresult codesorextended result codesmight be returned as well.

SQLITE_BUSYmeans that the database engine was unable to acquire the database locks it needs to do its job. If the statement is aCOMMITor occurs outside of an explicit transaction,then you can retry the statement. If the statement is not aCOMMITand occurs within an explicit transaction then you should rollback the transaction before continuing.

SQLITE_DONEmeans that the statement has finished executing successfully. sqlite3_step() should not be called again on this virtual machine without first callingsqlite3_reset()to reset the virtual machine back to its initial state.

If the sql statement being executed returns any data,thenSQLITE_ROWis returned each time a new row of data is ready for processing by the caller. The values may be accessed using thecolumn access functions. sqlite3_step() is called again to retrieve the next row of data.

SQLITE_ERRORmeans that a run-time error (such as a constraint violation) has occurred. sqlite3_step() should not be called again on the VM. More information may be found by callingsqlite3_errmsg(). With the legacy interface,a more specific error code (for example,100)" rel="nofollow" target="_blank">sqlITE_INTERRUPT,100)" rel="nofollow" target="_blank">sqlITE_SCHEMA,100)" rel="nofollow" target="_blank">sqlITE_CORRUPT,and so forth) can be obtained by callingsqlite3_reset()on theprepared statement. In the "v2" interface,the more specific error code is returned directly by sqlite3_step().

SQLITE_MISUSEmeans that the this routine was called inappropriately. Perhaps it was called on aprepared statementthat has already beenfinalizedor on one that had prevIoUsly returnedSQLITE_ERRORorSQLITE_DONE. Or it could be the case that the same database connection is being used by two or more threads at the same moment in time.

For all versions of sqlite up to and including 3.6.23.1,a call tosqlite3_reset()was required after sqlite3_step() returned anything other thanSQLITE_ROWbefore any subsequent invocation of sqlite3_step(). Failure to reset the prepared statement usingsqlite3_reset()would result in anSQLITE_MISUSEreturn from sqlite3_step(). But after version 3.6.23.1,sqlite3_step() began callingsqlite3_reset()automatically in this circumstance rather than returningSQLITE_MISUSE. This is not considered a compatibility break because any application that ever receives an sqlITE_MISUSE error is broken by definition. TheSQLITE_OMIT_AUTORESETcompile-time option can be used to restore the legacy behavior.

Goofy Interface Alert:In the legacy interface,the sqlite3_step() API always returns a generic error code,following any error other thanSQLITE_BUSYandSQLITE_MISUSE. You must callsqlite3_reset()orsqlite3_finalize()in order to find one of the specificerror codesthat better describes the error. We admit that this is a goofy design. The problem has been fixed with the "v2" interface. If you prepare all of your sql statements using eithersqlite3_prepare16_v2()instead of the legacysqlite3_prepare16()interfaces,then the more specificerror codesare returned directly by sqlite3_step(). The use of the "v2" interface is recommended.