|20:41||A better fix for the sqlite3_trace() problem. Ticket [11d5aa455e0d98f3c1e6a] (check-in: 44d5bd4c user: drh tags: trunk)|
|20:27||Make sure the sqlite3_trace() callback is invoked, even if the prepared statement was marked "expired" before it ever entered sqlite3_step(). Ticket [11d5aa455e0d98f3c1e6a08]. (check-in: 0d4d3df4 user: drh tags: trunk)|
|20:27||• Fixed ticket [11d5aa45]: sqlite3_trace() sometimes does not invoke its callback plus 5 other changes (artifact: 2be037cd user: drh)|
|19:57||• New ticket [11d5aa45]. (artifact: cc30ae32 user: drh)|
|Title:||sqlite3_trace() sometimes does not invoke its callback|
|Last Modified:||2014-08-19 20:27:37|
|Version Found In:||3.8.6|
drh added on 2014-08-19 19:57:38:
The callback to sqlite3_trace() is suppose to be invoked for every SQL statement that is run by the VDBE. But sometimes the callback will be suppressed. If the prepared statement is marked as expired (which can happen, for example, if the RHS of an expression like "x GLOB ?1" is rebound and X is an indexed text column) then the callback is not invoked. This can be seen in the shell by running:
.trace stderr .tables
The SELECT statement that implements the ".tables" command is not traced.
This problem appears to have existed since 2012-10-03, version 3.7.15 and check-in [39f763bfc04174ee0fe2cdf6a92]. The problem was discovered during internal testing and has not been observed in the wild.