Richard Hipp wrote:
On 7/29/18, Jürgen Palm <juergen_p...@online.de> wrote:
Hi,
in an application I encountered a problem, where the changing of the
structure of a table by dropping and recreating it via one connection to
a db was not directly seen by another connection to the same db.
Detecting a schema change requires starting a read transaction. The
sqlite3_step() interface (usually) starts a read transaction, and so
it will detect the schema change, and will cause the statement to
automatically adjust to the new schema. But sqlite3_column_count()
does *not* start a new transaction. The sqlite3_column_count() bases
its answer on whatever schema was current during last transaction for
that connection.
Thank you for the explanation. Although the behavior appears still a
little bit wrong to me, I can live with it and I understand, that it
might cause performance issues for bulk operations for example, if for
each statement a schema change needs to be checked, although it's not
necessary.
As a quick, ugly workaround for my situation I could add something like
sqlite3_exec(conn1, "SELECT 1",NULL,NULL,NULL);
before the sqlite3_prepare_v2 after the schema change.
Is there any better way? Or would it be possible to add a SQLITE_PREPARE
flag to sqlite3_prepare_v3, which forces a schema change check?
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
