SQLite

Check-in [d1b3c54f42]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment: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.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | step-autoreset
Files: files | file ages | folders
SHA1: d1b3c54f42b1765e7565aeff517835c28528b177
User & Date: drh 2011-01-11 01:42:47.257
Original Comment: 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.
Context
2011-01-11
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: d1b3c54f42 user: drh tags: step-autoreset)
2011-01-10
21:01
Update pager requirements to account for the ZIPVFS extension. (check-in: d94e59b514 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
install-sh became executable.
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);
test/progress.test became a regular file.
tool/mkopts.tcl became a regular file.