SQLite

View Ticket
Login
Ticket Hash: 8d510499ccbac2f03efaf6dd0567d0e01a88a012
Title: Repreparation errors are always returned as SQLITE_SCHEMA
Status: Closed Type: Code_Defect
Severity: Important Priority: Immediate
Subsystem: Parser Resolution: Works_As_Designed
Last Modified: 2009-10-20 13:27:15
15.67 years ago
Created: 2009-10-19 05:23:33
15.68 years ago
Version Found In: 3.5.5
Description:
See http://www.sqlite.org/cvstrac/tktview?tn=2922 including test and patch.

The problem is that SQLITE_SCHEMA occurs then no matter what the error on reprepare SQLITE_SCHEMA is returned. For example the database could be busy but you won't get SQLITE_BUSY returned.


rogerb added on 2009-10-19 05:28:02:
This bug also affects me with APSW and I reverted to using prepare version 1 because of it. My real world occurrence was when a collation was removed after the statement had been prepared. If you do a fresh prepare then you get SQLERROR but on a reprepare you get SCHEMA. Since I have a statement cache the actual library user has no knowledge of what statements are already prepared and which aren't nor should they care.


rogerb added on 2009-10-20 00:38:59:
Also http://www.sqlite.org/cvstrac/tktview?tn=2158


drh added on 2009-10-20 13:27:15:
sqlite3_prepare_v2() will return SQLITE_ERROR if there is a missing collating function. But sqlite3_step() returns SQLITE_SCHEMA when it goes to reprepare a statement and the collating function has gone missing. We have decided that this is a feature, not a bug. We want sqlite3_step() to return SQLITE_SCHEMA instead of SQLITE_ERROR in order to emphasize that the application has hit a compile-time rather than a run-time error. This is the unanimous decision of the developers.