Sorry for being dense, but I don't understand what you are saying.
What do you mean by "prepare a transaction"? Transactions are not
prepared, statements are. sqlite3_prepare is not part of a
transaction, does not initiate a transaction, and is not affected by
any ongoing transaction in any way, shape or form. The first call to
sqlite3_step on a prepared statement initiates the transaction
(assuming there is no explicitly started transaction in place on the
database handle). SQLITE_SCHEMA error arises when another process or
thread changes the schema between sqlite3_prepare (or sqlite3_reset)
and sqlite3_step.
If your usage pattern is something like
begin transaction
prepare
step
step
...
finalize
commit
then you don't need to worry about SQLITE_SCHEMA under the existing
engine. The whole issue becomes moot. Of course you are losing one
of the benefits of prepared statements - time saving due to
elimination of unnecessary parsing and execution planning.
Igor Tandetnik
Well, i use sqlite without threads, the os where it's used hasn't
thread support and there is one app with sqlite only, so only one
process and only one transaction is on the way. That's why i say my
point of view maybe a bit obfuscated. I only tried to look for other
ways to avoid SQLITE_SCHEMA errors, re-prepare other threads is a bit
expensive in cpu cycles, at least for me.
Thanks for your time ;)
-----------------------------------------------------------------------------------------------------------------------------
La diferencia entre la teoria y la practica es que en teoria no hay,
pero en la practica si
