1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/os/persistentdata/persistentstorage/sqlite3api/TEST/TclScript/tkt2820.test	Fri Jun 15 03:10:57 2012 +0200
     1.3 @@ -0,0 +1,94 @@
     1.4 +# 2007 Dec 4
     1.5 +#
     1.6 +# The author disclaims copyright to this source code. In place of
     1.7 +# a legal notice, here is a blessing:
     1.8 +#
     1.9 +#    May you do good and not evil.
    1.10 +#    May you find forgiveness for yourself and forgive others.
    1.11 +#    May you share freely, never taking more than you give.
    1.12 +#
    1.13 +#***********************************************************************
    1.14 +#
    1.15 +# This file is to test that ticket #2820 has been fixed.
    1.16 +# Ticket #2820 observes that a DROP TABLE statement that
    1.17 +# occurs while a query is in process will fail with a
    1.18 +# "database is locked" error, but the entry in the sqlite_master
    1.19 +# table will still be removed.  This is incorrect.  The
    1.20 +# entry in the sqlite_master table should persist when 
    1.21 +# the DROP fails due to an error.
    1.22 +#
    1.23 +# $Id: tkt2820.test,v 1.1 2007/12/04 16:54:53 drh Exp $
    1.24 +#
    1.25 +
    1.26 +set testdir [file dirname $argv0]
    1.27 +source $testdir/tester.tcl
    1.28 +
    1.29 +proc test_schema_change {testid init ddl res} {
    1.30 +  db close
    1.31 +  file delete -force test.db test.db-journal
    1.32 +  sqlite3 db test.db
    1.33 +  execsql $init
    1.34 +  do_test tkt2820-$testid.1 {
    1.35 +    set STMT [sqlite3_prepare db {SELECT * FROM sqlite_master} -1 DUMMY]
    1.36 +    sqlite3_step $STMT
    1.37 +  } {SQLITE_ROW}
    1.38 +#if {$testid==3} {execsql {PRAGMA vdbe_trace=ON}}
    1.39 +  do_test tkt2820-$testid.2 "catchsql [list $ddl]" \
    1.40 +       {1 {database table is locked}}
    1.41 +  do_test tkt2820-$testid.3 {
    1.42 +    sqlite3_finalize $STMT
    1.43 +    execsql {SELECT name FROM sqlite_master ORDER BY 1}
    1.44 +  } $res
    1.45 +  integrity_check tkt2820-$testid.4
    1.46 +  db close
    1.47 +  sqlite3 db test.db
    1.48 +  integrity_check tkt2820-$testid.5
    1.49 +}
    1.50 +
    1.51 +test_schema_change 1 {
    1.52 +  CREATE TABLE t1(a);
    1.53 +} {
    1.54 +  DROP TABLE t1
    1.55 +} {t1}
    1.56 +test_schema_change 2 {
    1.57 +  CREATE TABLE t1(a);
    1.58 +  CREATE TABLE t2(b);
    1.59 +} {
    1.60 +  DROP TABLE t2
    1.61 +} {t1 t2}
    1.62 +test_schema_change 3 {
    1.63 +  CREATE TABLE t1(a);
    1.64 +  CREATE INDEX i1 ON t1(a);
    1.65 +} {
    1.66 +  DROP INDEX i1
    1.67 +} {i1 t1}
    1.68 +
    1.69 +# We further observe that prior to the fix associated with ticket #2820,
    1.70 +# no statement journal would be created on an SQL statement that was run
    1.71 +# while a second statement was active, as long as we are in autocommit
    1.72 +# mode.  This is incorrect.
    1.73 +#
    1.74 +do_test tkt2820-4.1 {
    1.75 +  db close
    1.76 +  file delete -force test.db test.db-journal
    1.77 +  sqlite3 db test.db
    1.78 +  db eval {
    1.79 +    CREATE TABLE t1(a INTEGER PRIMARY KEY);
    1.80 +    INSERT INTO t1 VALUES(1);
    1.81 +    INSERT INTO t1 VALUES(2);
    1.82 +  }
    1.83 +
    1.84 +  # The INSERT statement within the loop should fail on a
    1.85 +  # constraint violation on the second inserted row.  This
    1.86 +  # should cause the entire INSERT to rollback using a statement
    1.87 +  # journal.
    1.88 +  #
    1.89 +  db eval {SELECT name FROM sqlite_master} {
    1.90 +    catch {db eval {
    1.91 +      INSERT INTO t1 SELECT a+1 FROM t1 ORDER BY a DESC
    1.92 +    }}
    1.93 +  }
    1.94 +  db eval {SELECT a FROM t1 ORDER BY a}
    1.95 +} {1 2}
    1.96 +
    1.97 +finish_test