SQLite

Check-in [31a661d424]
Login

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

Overview
Comment:Documentation and tests to show that the cause of a parsing error is available on sqlite3_errmsg after sqlite3_step return SQLITE_SCHEMA. (CVS 3581)
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 31a661d424d0fe03eaf78f98031e360102dafeff
User & Date: drh 2007-01-09 15:06:42.000
Context
2007-01-09
15:32
Work around win2k problems so that single-character filenames can be used. Ticket #2151. (CVS 3582) (check-in: c4eb2100c3 user: drh tags: trunk)
15:06
Documentation and tests to show that the cause of a parsing error is available on sqlite3_errmsg after sqlite3_step return SQLITE_SCHEMA. (CVS 3581) (check-in: 31a661d424 user: drh tags: trunk)
15:02
Updates tests and documentation to justify the behavior observed in ticket #2158. No changes to code. (CVS 3580) (check-in: e1f7cf065d user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to test/capi3c.test.
︙︙
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#
#***********************************************************************
# This file implements regression tests for SQLite library.  
#
# This is a copy of the capi3.test file that has been adapted to
# test the new sqlite3_prepare_v2 interface.
#
# $Id: capi3c.test,v 1.4 2007/01/09 15:02:03 drh Exp $
#

set testdir [file dirname $argv0]
source $testdir/tester.tcl

# Return the UTF-16 representation of the supplied UTF-8 string $str.
# If $nt is true, append two 0x00 bytes as a nul terminator.








|








9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#
#***********************************************************************
# This file implements regression tests for SQLite library.  
#
# This is a copy of the capi3.test file that has been adapted to
# test the new sqlite3_prepare_v2 interface.
#
# $Id: capi3c.test,v 1.5 2007/01/09 15:06:42 drh Exp $
#

set testdir [file dirname $argv0]
source $testdir/tester.tcl

# Return the UTF-16 representation of the supplied UTF-8 string $str.
# If $nt is true, append two 0x00 bytes as a nul terminator.
︙︙
1171
1172
1173
1174
1175
1176
1177



1178
1179
1180
1181
1182
1183
1184

  sqlite3_step $STMT
} SQLITE_DONE
do_test capi3c-19.4 {
  sqlite3_reset $STMT
  db eval {DROP TABLE t3}
  sqlite3_step $STMT
} SQLITE_SCHEMA



do_test capi3c-19.5 {
  sqlite3_reset $STMT
  db eval {
     CREATE TABLE t3(x,y);
     INSERT INTO t3 VALUES(1,2);
  }
  sqlite3_step $STMT








>
>
>








1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187

  sqlite3_step $STMT
} SQLITE_DONE
do_test capi3c-19.4 {
  sqlite3_reset $STMT
  db eval {DROP TABLE t3}
  sqlite3_step $STMT
} SQLITE_SCHEMA
do_test capi3c-19.4.2 {
  sqlite3_errmsg $DB
} {no such table: t3}
do_test capi3c-19.5 {
  sqlite3_reset $STMT
  db eval {
     CREATE TABLE t3(x,y);
     INSERT INTO t3 VALUES(1,2);
  }
  sqlite3_step $STMT
︙︙
Changes to www/capi3ref.tcl. 
1
2
3
4
5
6
7
8

set rcsid {$Id: capi3ref.tcl,v 1.48 2007/01/09 15:02:03 drh Exp $}
source common.tcl
header {C/C++ Interface For SQLite Version 3}
puts {
<h2>C/C++ Interface For SQLite Version 3</h2>
}

proc api {name prototype desc {notused x}} {

|








1
2
3
4
5
6
7
8

set rcsid {$Id: capi3ref.tcl,v 1.49 2007/01/09 15:06:42 drh Exp $}
source common.tcl
header {C/C++ Interface For SQLite Version 3}
puts {
<h2>C/C++ Interface For SQLite Version 3</h2>
}

proc api {name prototype desc {notused x}} {
︙︙
1192
1193
1194
1195
1196
1197
1198
1199

1200
1201
1202
1203
1204
1205
1206

 <li>
 If the database schema changes, instead of returning SQLITE_SCHEMA as it
 always used to do, sqlite3_step() will automatically recompile the SQL
 statement and try to run it again.  If the schema has changed in a way
 that makes the statement no longer valid, sqlite3_step() will still
 return SQLITE_SCHEMA.  But unlike the legacy behavior, SQLITE_SCHEMA is
 now a fatal error.  Calling sqlite3_prepare_v2() again will not make the
 error go away.

 </li>

 <li>
 When an error occurs, 
 sqlite3_step() will return one of the detailed result-codes
 like SQLITE_IOERR or SQLITE_FULL or SQLITE_SCHEMA directly. The
 legacy behavior was that sqlite3_step() would only return a generic








|
>








1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207

 <li>
 If the database schema changes, instead of returning SQLITE_SCHEMA as it
 always used to do, sqlite3_step() will automatically recompile the SQL
 statement and try to run it again.  If the schema has changed in a way
 that makes the statement no longer valid, sqlite3_step() will still
 return SQLITE_SCHEMA.  But unlike the legacy behavior, SQLITE_SCHEMA is
 now a fatal error.  Calling sqlite3_prepare_v2() again will not make the
 error go away.  Note: use sqlite3_errmsg() to find the text of the parsing
 error that results in an SQLITE_SCHEMA return.
 </li>

 <li>
 When an error occurs, 
 sqlite3_step() will return one of the detailed result-codes
 like SQLITE_IOERR or SQLITE_FULL or SQLITE_SCHEMA directly. The
 legacy behavior was that sqlite3_step() would only return a generic
︙︙