On 10/14/2016 04:59 PM, Hick Gunter wrote:
In the vdbeaux.c source, the function
resolveP2Values(...)
is not resetting p->readOnly when it encounters an OP_VUpdate opcode
is not setting p->bIsReader when it encounters an OP_VFilter opcode
Additionally, the frunction
sqlite3VdbeHalt(...)
is only checking p->bIsReader and omitting to check p->readOnly
even though the comment claims to check "if the program never started or if the SQL
Statement does not read or write a database file".
These omissions conspire to make SQLite refrain from calling the xSync and
xCommit entrypoints of the virtual table named in an UPDATE, DELETE or INSERT
statement.
Do you have a test case for this?
Trying to reproduce here, all VM programs for UPDATE/DELETE/INSERT also
contain OP_Transaction opcodes. Which cause Vdbe.bIsReader to be set and
so the xSync/xCommit methods are called. Do the VM programs (EXPLAIN
output) for whatever statements you're testing with contain the
OP_Transaction?
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
