> > Suppose this where to change in version 3.3.0 so that the > > actual error code was returned by sqlite3_step().
That would be a good thing, since it would allow appropriate reaction at the right time and the right place. > > Then when a schema change occurred, the statement was automatically > > recompiled and rebound. There would no more SQLITE_SCHEMA errors. > > This change should be done. SQLITE_SCHEMA is all about > an internal implementation detail in SQLite and shouldn't > really be exposed to the users of SQLite. There is only > action that people take on getting it - rerun the query. > Pretty much every wrapper does that anyway so it makes > even more sense to make that the standard code in SQLite. Sure, it would be nice if SQLITE_SCHEMA errors could be handled internally by SQLite, but I think it's a non-trivial task to handle this kind of error. When I created my SQLite C++ wrapper wxSQLite3 I thought about handling SCHEMA errors, but decided against it due to the complexities involved. For example which reaction is appropriate depends on the kind of the SQL statement: For INSERT, UPDATE or DELETE a simple retry might be a good choice. But how often should the retry take place? The SQLite FAQ code example contains an endless loop! I didn't want to introduce such kind of code into wxSQLite3. - Additionally the number of columns in a table used in these statements might have changed, that is the statement would probably fail again. In case of a SELECT statement the situation is still more complex. The SCHEMA error could happen after reading several result rows. If you would then redo the query automatically it would start from scratch delivering the already read rows again. If your application code gathers the result set in an array for example you would get duplicate rows. When retrying a query another problem arises if the SQL statement contains bind variables. You would have to rebind the variables. To handle this automatically would induce a lot of extra house keeping, wouldn't it? If SQLite would be able to handle all these issues transparently, it would be ok for me. > If you are looking at API changes, the most beneficial to > me would be a unification of sqlite3_value_TYPE and > sqlite3_column_TYPE. I have to write identical code to > do my own type conversion when calling these function > and duplicate it. Similar story with sqlite3_result_TYPE > and sqlite3_bind_TYPE. Since C++ variables are typed my wrapper wxSQLite3 needs no type conversion. It's the user's responsibility to use variables of the right type. There is only one place where I would appreciate to have type information at hand. sqlite3_get_table returns all values as character strings and there is no way to find out the original value types. Regards, Ulrich Telle -- Ulrich Telle E-Mail privat: mailto:[EMAIL PROTECTED] E-Mail Studium: mailto:[EMAIL PROTECTED] Homepage: http://www.stud.fernuni-hagen.de/q1471341 Fax: +49-(0)89-1488-203070
