Jan-Henrik Haukeland wrote:
Instead of this workaround, it would be much better if we could change Connection_lastRowId() to work with postgresql somehow. Any ideas anyone?
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, so it's not critical - unlike the mysql bug :-(.
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...
later,