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 );
What's the point of running a SELECT statement without actually
reading the returned rows?
It's simple example, not real code. Only show strategy.
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 );
Why do you want to keep running the same statement over and over?
Since I guarante that there is no errors in SQL syntax something when
ret != SQLITE_OK mean that there is concurrency problem and I need to
wait unloking database. For that reason I keep the same statement over
and over.
}
sqlite3_exec( db, "END", 0, 0, 0 );
More dangerous when "COMMIT" after "INSERT" return SQLITE_BUSY!!!
I'm not sure I understand what your point is here. You have a reader
that hogs the database forever in a long-running transaction. Of
course writers are locked out.
No. Reader will not hog database because if in this example ret !=
SQLITE_OK then writer have already lock database for write and we need
to wait for unlocking. And when I wrote: "More dangerous when "COMMIT"
after "INSERT" return SQLITE_BUSY" I mean that if this wouldn't be
checked then probably we lost ours data.
P.S. There is no reasons for two threads lock the same database and will
run while cycle at the same time.
--
Regards,
Igor Mironchick,
Intervale ©
#ICQ 492-597-570
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
