View Ticket
A better fix for the sqlite3_trace() problem. Ticket [11d5aa455e0d98f3c1e6a] (check-in: 44d5bd4c user: drh tags: trunk)
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)

Ticket Hash: 11d5aa455e0d98f3c1e6a084a89309710458ee4d
Title: sqlite3_trace() sometimes does not invoke its callback
Status: Fixed Type: Code_Defect
Severity: Minor Priority: Immediate
Subsystem: Unknown Resolution: Fixed
Last Modified: 2014-08-19 20:27:37
Version Found In: 3.8.6
User Comments:
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

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.