Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch step-autoreset Excluding Merge-Ins
This is equivalent to a diff from d94e59b5 to d1b3c54f
2011-01-11
| ||
12:46 | Fix the sqlite3.h generator script so that it generates the correct SQLITE_SOURCE_ID string with the latest versions of Fossil that include fractional seconds on the date/time stamp. (check-in: 3513bf6e user: drh tags: trunk) | |
01:42 | A proposed change to the sqlite3_step() API such that it will only auto-reset following an SQLITE_BUSY or SQLITE_LOCKED error. Calls after any other result other than SQLITE_ROW will return SQLITE_MISUSE. (Closed-Leaf check-in: d1b3c54f user: drh tags: step-autoreset) | |
2011-01-10
| ||
21:01 | Update pager requirements to account for the ZIPVFS extension. (check-in: d94e59b5 user: drh tags: trunk) | |
2011-01-07
| ||
02:50 | Reorder the fields in private structures in an effort to reduce alignment gaps and thus make the structures smaller, and to put frequently accessed fields first. Also update some obsolete comments. Valgrind shows a very slight performance improvement. (check-in: 378a1d13 user: drh tags: trunk) | |
Changes to src/sqlite.h.in.
︙ | ︙ | |||
3067 3068 3069 3070 3071 3072 3073 | ** [SQLITE_MISUSE] means that the this routine was called inappropriately. ** Perhaps it was called on a [prepared statement] that has ** already been [sqlite3_finalize | finalized] or on one that had ** previously returned [SQLITE_ERROR] or [SQLITE_DONE]. Or it could ** be the case that the same database connection is being used by two or ** more threads at the same moment in time. ** | | | | | > > > > > | 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 | ** [SQLITE_MISUSE] means that the this routine was called inappropriately. ** Perhaps it was called on a [prepared statement] that has ** already been [sqlite3_finalize | finalized] or on one that had ** previously returned [SQLITE_ERROR] or [SQLITE_DONE]. Or it could ** be the case that the same database connection is being used by two or ** more threads at the same moment in time. ** ** For all versions of SQLite prior to 3.7.0, it was required ** after sqlite3_step() returned anything other than [SQLITE_ROW] that ** [sqlite3_reset()] be called before any subsequent invocation of ** sqlite3_step(). Failure to invoke [sqlite3_reset()] in this way would ** result in an [SQLITE_MISUSE] return from sqlite3_step(). Beginning ** with version 3.7.0, sqlite3_step() began calling [sqlite3_reset()] ** automatically in this circumstance rather than returning [SQLITE_MISUSE]. ** This changed again in version 3.7.5 such that [sqlite3_reset()] is ** only invoked after an [SQLITE_BUSY] or [SQLITE_LOCKED] error return ** and in all other cases sqlite3_step() will return [SQLITE_MISUSE] if ** it is not manually reset following [SQLITE_DONE] or any error other ** than [SQLITE_BUSY] and [SQLITE_LOCKED]. ** ** <b>Goofy Interface Alert:</b> In the legacy interface, the sqlite3_step() ** API always returns a generic error code, [SQLITE_ERROR], following any ** error other than [SQLITE_BUSY] and [SQLITE_MISUSE]. You must call ** [sqlite3_reset()] or [sqlite3_finalize()] in order to find one of the ** specific [error codes] that better describes the error. ** We admit that this is a goofy design. The problem has been fixed |
︙ | ︙ |
Changes to src/vdbeapi.c.
︙ | ︙ | |||
340 341 342 343 344 345 346 | */ static int sqlite3Step(Vdbe *p){ sqlite3 *db; int rc; assert(p); if( p->magic!=VDBE_MAGIC_RUN ){ | > | | | | > > | | > > > | 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 | */ static int sqlite3Step(Vdbe *p){ sqlite3 *db; int rc; assert(p); if( p->magic!=VDBE_MAGIC_RUN ){ if( p->rc==SQLITE_BUSY || p->rc==SQLITE_LOCKED ){ /* We used to require that sqlite3_reset() be called before retrying ** sqlite3_step() after any error. But after 3.6.23, we changed this ** so that sqlite3_reset() would be called automatically instead of ** throwing the error. Then for 3.7.5 we change it again so that ** sqlite3_reset() would be automatically called only after BUSY and ** LOCKED errors. */ sqlite3_reset((sqlite3_stmt*)p); }else{ return SQLITE_MISUSE_BKPT; } } /* Check that malloc() has not failed. If it has, return early. */ db = p->db; if( db->mallocFailed ){ p->rc = SQLITE_NOMEM; return SQLITE_NOMEM; |
︙ | ︙ |
Changes to test/capi2.test.
︙ | ︙ | |||
67 68 69 70 71 72 73 | } {name rowid text INTEGER} do_test capi2-1.6 { sqlite3_step $VM } {SQLITE_DONE} do_test capi2-1.7 { list [sqlite3_column_count $VM] [get_row_values $VM] [get_column_names $VM] } {2 {} {name rowid text INTEGER}} | < < < | | 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 | } {name rowid text INTEGER} do_test capi2-1.6 { sqlite3_step $VM } {SQLITE_DONE} do_test capi2-1.7 { list [sqlite3_column_count $VM] [get_row_values $VM] [get_column_names $VM] } {2 {} {name rowid text INTEGER}} do_test capi2-1.8 { sqlite3_step $VM } {SQLITE_MISUSE} # Update: In v2, once SQLITE_MISUSE is returned the statement handle cannot # be interrogated for more information. However in v3, since the column # count, names and types are determined at compile time, these are still # accessible after an SQLITE_MISUSE error. do_test capi2-1.9 { sqlite3_reset $VM |
︙ | ︙ |
Changes to test/fkey2.test.
︙ | ︙ | |||
1412 1413 1414 1415 1416 1417 1418 | } {1} do_test fkey2-17.1.2 { set STMT [sqlite3_prepare_v2 db "INSERT INTO two VALUES(4, 5, 6)" -1 dummy] sqlite3_step $STMT } {SQLITE_CONSTRAINT} do_test fkey2-17.1.3 { sqlite3_step $STMT | | | 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 | } {1} do_test fkey2-17.1.2 { set STMT [sqlite3_prepare_v2 db "INSERT INTO two VALUES(4, 5, 6)" -1 dummy] sqlite3_step $STMT } {SQLITE_CONSTRAINT} do_test fkey2-17.1.3 { sqlite3_step $STMT } {SQLITE_MISUSE} do_test fkey2-17.1.4 { sqlite3_finalize $STMT } {SQLITE_CONSTRAINT} do_test fkey2-17.1.5 { execsql { INSERT INTO one VALUES(2, 3, 4); INSERT INTO one VALUES(3, 4, 5); |
︙ | ︙ |