On 2. mai. 2008, at 09.35, Paul J Stevens wrote:
Jan-Henrik Haukeland wrote:
And yes, reusing a prepared statement after it returns a result set is problematic for SQLite, hence Connection_clear() was exposed. Creating a new statement for the result set instead of reusing the prepared one should work, but it has not been a big enough nag to refactor.
It's not a big problem for me either - yet. But it does impose a specific pattern in my code that is not evident at first glance. This is only an issue during big loops triggering massive amounts of insert queries, each of which *must* return the lastrowid. But that only affects throughput,
Well, almost all of this would not be necessary if a workaround for Connection_lastRowId() on postgres could be found. This is the root cause and trying to find a solution for this, if possible, would be best.
so it's not critical - unlike the mysql bug :-(.
Yes, the mysql bug is very bad, and a workaround *must* be found. I'll look into that.
I also noticed you're using the deprecated sqlite3 interface for statements, right? I'm asking because I'm seeing very undescriptive errors raised by executing statements in the sqlite code: SQL logic error or missing database.
It looks like all that is needed is replacing sqlite3_prepare with sqlite3_prepare_v2. I'll do some testing today...
sqlite3_prepare_v2() was first added in SQLite version 3.3.9 and libzdb should work with 3.x. But you are right, using this interface, if available, is preferable with regards to error reporting. I'll use an #ifdef to add it.