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

install-sh became executable.

Changes to src/sqlite.h.in.

  3067   3067   ** [SQLITE_MISUSE] means that the this routine was called inappropriately.
  3068   3068   ** Perhaps it was called on a [prepared statement] that has
  3069   3069   ** already been [sqlite3_finalize | finalized] or on one that had
  3070   3070   ** previously returned [SQLITE_ERROR] or [SQLITE_DONE].  Or it could
  3071   3071   ** be the case that the same database connection is being used by two or
  3072   3072   ** more threads at the same moment in time.
  3073   3073   **
  3074         -** For all versions of SQLite up to and including 3.6.23.1, it was required
         3074  +** For all versions of SQLite prior to 3.7.0, it was required
  3075   3075   ** after sqlite3_step() returned anything other than [SQLITE_ROW] that
  3076   3076   ** [sqlite3_reset()] be called before any subsequent invocation of
  3077   3077   ** sqlite3_step().  Failure to invoke [sqlite3_reset()] in this way would
  3078         -** result in an [SQLITE_MISUSE] return from sqlite3_step().  But after
  3079         -** version 3.6.23.1, sqlite3_step() began calling [sqlite3_reset()] 
  3080         -** automatically in this circumstance rather than returning [SQLITE_MISUSE].  
         3078  +** result in an [SQLITE_MISUSE] return from sqlite3_step().  Beginning
         3079  +** with version 3.7.0, sqlite3_step() began calling [sqlite3_reset()] 
         3080  +** automatically in this circumstance rather than returning [SQLITE_MISUSE].
         3081  +** This changed again in version 3.7.5 such that [sqlite3_reset()] is
         3082  +** only invoked after an [SQLITE_BUSY] or [SQLITE_LOCKED] error return
         3083  +** and in all other cases sqlite3_step() will return [SQLITE_MISUSE] if
         3084  +** it is not manually reset following [SQLITE_DONE] or any error other
         3085  +** than [SQLITE_BUSY] and [SQLITE_LOCKED].
  3081   3086   **
  3082   3087   ** <b>Goofy Interface Alert:</b> In the legacy interface, the sqlite3_step()
  3083   3088   ** API always returns a generic error code, [SQLITE_ERROR], following any
  3084   3089   ** error other than [SQLITE_BUSY] and [SQLITE_MISUSE].  You must call
  3085   3090   ** [sqlite3_reset()] or [sqlite3_finalize()] in order to find one of the
  3086   3091   ** specific [error codes] that better describes the error.
  3087   3092   ** We admit that this is a goofy design.  The problem has been fixed

Changes to src/vdbeapi.c.

   340    340   */
   341    341   static int sqlite3Step(Vdbe *p){
   342    342     sqlite3 *db;
   343    343     int rc;
   344    344   
   345    345     assert(p);
   346    346     if( p->magic!=VDBE_MAGIC_RUN ){
   347         -    /* We used to require that sqlite3_reset() be called before retrying
   348         -    ** sqlite3_step() after any error.  But after 3.6.23, we changed this
   349         -    ** so that sqlite3_reset() would be called automatically instead of
   350         -    ** throwing the error.
   351         -    */
   352         -    sqlite3_reset((sqlite3_stmt*)p);
          347  +    if( p->rc==SQLITE_BUSY || p->rc==SQLITE_LOCKED ){
          348  +      /* We used to require that sqlite3_reset() be called before retrying
          349  +      ** sqlite3_step() after any error.  But after 3.6.23, we changed this
          350  +      ** so that sqlite3_reset() would be called automatically instead of
          351  +      ** throwing the error.  Then for 3.7.5 we change it again so that
          352  +      ** sqlite3_reset() would be automatically called only after BUSY and
          353  +      ** LOCKED errors.
          354  +      */
          355  +      sqlite3_reset((sqlite3_stmt*)p);
          356  +    }else{
          357  +      return SQLITE_MISUSE_BKPT;
          358  +    }
   353    359     }
   354    360   
   355    361     /* Check that malloc() has not failed. If it has, return early. */
   356    362     db = p->db;
   357    363     if( db->mallocFailed ){
   358    364       p->rc = SQLITE_NOMEM;
   359    365       return SQLITE_NOMEM;

Changes to test/capi2.test.

    67     67   } {name rowid text INTEGER}
    68     68   do_test capi2-1.6 {
    69     69     sqlite3_step $VM 
    70     70   } {SQLITE_DONE}
    71     71   do_test capi2-1.7 {
    72     72     list [sqlite3_column_count $VM] [get_row_values $VM] [get_column_names $VM]
    73     73   } {2 {} {name rowid text INTEGER}}
    74         -
    75         -# This used to be SQLITE_MISUSE.  But now we automatically reset prepared
    76         -# statements.
    77     74   do_test capi2-1.8 {
    78     75     sqlite3_step $VM
    79         -} {SQLITE_ROW}
           76  +} {SQLITE_MISUSE}
    80     77   
    81     78   # Update: In v2, once SQLITE_MISUSE is returned the statement handle cannot
    82     79   # be interrogated for more information. However in v3, since the column
    83     80   # count, names and types are determined at compile time, these are still
    84     81   # accessible after an SQLITE_MISUSE error.
    85     82   do_test capi2-1.9 {
    86     83     sqlite3_reset $VM

Changes to test/fkey2.test.

  1412   1412   } {1}
  1413   1413   do_test fkey2-17.1.2 {
  1414   1414     set STMT [sqlite3_prepare_v2 db "INSERT INTO two VALUES(4, 5, 6)" -1 dummy]
  1415   1415     sqlite3_step $STMT
  1416   1416   } {SQLITE_CONSTRAINT}
  1417   1417   do_test fkey2-17.1.3 {
  1418   1418     sqlite3_step $STMT
  1419         -} {SQLITE_CONSTRAINT}
         1419  +} {SQLITE_MISUSE}
  1420   1420   do_test fkey2-17.1.4 {
  1421   1421     sqlite3_finalize $STMT
  1422   1422   } {SQLITE_CONSTRAINT}
  1423   1423   do_test fkey2-17.1.5 {
  1424   1424     execsql {
  1425   1425       INSERT INTO one VALUES(2, 3, 4);
  1426   1426       INSERT INTO one VALUES(3, 4, 5);

test/progress.test became a regular file.

tool/mkopts.tcl became a regular file.