SQLite: View Ticket

2009-10-20
13:27		• Closed ticket [8d510499cc]: Repreparation errors are always returned as SQLITE_SCHEMA plus 2 other changes (artifact: 0e10289d76 user: drh)
00:38		• Ticket [8d510499cc]: 1 change (artifact: 6763db5cfc user: rogerb)
2009-10-19
05:28		• Ticket [8d510499cc]: 3 changes (artifact: 22707dc0cf user: rogerb)
05:23		• New ticket [8d510499cc]. (artifact: 85cf4da352 user: rogerb)

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.72 years ago	Created:	2009-10-19 05:23:33 15.72 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.