/ Changes On Branch step-autoreset
Login
SQLite training in Houston TX on 2019-11-05 (details)
Part of the 2019 Tcl Conference

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
3074
3075
3076
3077
3078
3079
3080





3081
3082
3083
3084
3085
3086
3087
** [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 up to and including 3.6.23.1, 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().  But after
** version 3.6.23.1, sqlite3_step() began calling [sqlite3_reset()] 
** automatically in this circumstance rather than returning [SQLITE_MISUSE].  





**
** <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







|



|
|
|
>
>
>
>
>







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

347
348
349
350


351
352



353
354
355
356
357
358
359
*/
static int sqlite3Step(Vdbe *p){
  sqlite3 *db;
  int rc;

  assert(p);
  if( p->magic!=VDBE_MAGIC_RUN ){

    /* 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.


    */
    sqlite3_reset((sqlite3_stmt*)p);



  }

  /* Check that malloc() has not failed. If it has, return early. */
  db = p->db;
  if( db->mallocFailed ){
    p->rc = SQLITE_NOMEM;
    return SQLITE_NOMEM;







>
|
|
|
|
>
>
|
|
>
>
>







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
74
75
76
77
78
79
80
81
82
83
84
85
86
} {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}}

# This used to be SQLITE_MISUSE.  But now we automatically reset prepared
# statements.
do_test capi2-1.8 {
  sqlite3_step $VM
} {SQLITE_ROW}

# 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







<
<
<


|







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
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_CONSTRAINT}
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);







|







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);