How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
As I understand it the deferred lock capability is conducive to better
concurrency, but does have other effects requiring that provision be
made to intercept a BUSY in the body of the transaction.
Ok. But this situation are more preferable for me that "BEGIN EXCLUSIVE".
What about this:
char * errors;
// I guarante that here no errors in SQL syntaxis.
char * sql = "SELECT * FROM data";
sqlite3_exec( db, "BEGIN", 0, 0, 0 );
int ret = sqlite3_exec( db, sql, 0, 0, &errors );
while( ret != SQLITE_OK )
{
std::cerr << "There is some errors while executing SQL statement: "
<< errors << std::endl;
sqlite3_free( errors );
ret = sqlite3_exec( db, sql, 0, 0, &errors );
}
sqlite3_exec( db, "END", 0, 0, 0 );
More dangerous when "COMMIT" after "INSERT" return SQLITE_BUSY!!!
--
Regards,
Igor Mironchick,
Intervale ©
#ICQ 492-597-570
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
