Have queries interrupted by the progress-handler return SQLITE_INTERRUPT. Rollback any active transaction if a DML statement returns SQLITE_INTERRUPT. (CVS 4061)

FossilOrigin-Name: 33454b5691637da7ded7d18d7f5726b796260c6b

2 files changed, 19 insertions, 10 deletions

diff --git a/test/interrupt.test b/test/interrupt.test
index 520580357..b348baa6b 100644
--- a/test/interrupt.test
+++ b/test/interrupt.test
@@ -11,7 +11,7 @@
 # This file implements regression tests for SQLite library.  The
 # focus of this script is the sqlite_interrupt() API.
 #
-# $Id: interrupt.test,v 1.14 2007/05/15 16:51:37 drh Exp $
+# $Id: interrupt.test,v 1.15 2007/06/13 16:49:49 danielk1977 Exp $
 
 
 set testdir [file dirname $argv0]
@@ -122,6 +122,10 @@ integrity_check interrupt-2.6
 # and that transaction is later rolled back, the internal schema tables do
 # not reset.
 #
+# UPDATE: Interrupting a DML statement in the middle of a transaction now
+# causes the transaction to roll back. Leaving the transaction open after
+# an SQL statement was interrupted halfway through risks database corruption.
+#
 ifcapable tempdb {
   for {set i 1} {$i<50} {incr i 5} {
     do_test interrupt-3.$i.1 {
@@ -141,12 +145,12 @@ ifcapable tempdb {
       execsql {
         SELECT name FROM sqlite_temp_master;
       }
-    } {t2}
+    } {}
     do_test interrupt-3.$i.4 {
       catchsql {
         ROLLBACK
       }
-    } {0 {}}
+    } {1 {cannot rollback - no transaction is active}}
     do_test interrupt-3.$i.5 {
       catchsql {SELECT name FROM sqlite_temp_master};
       execsql {
diff --git a/test/progress.test b/test/progress.test
index 5616a7afd..ca30b26ab 100755
--- a/test/progress.test
+++ b/test/progress.test
@@ -11,7 +11,7 @@
 # This file implements regression tests for SQLite library.  The
 # focus of this file is testing the 'progress callback'.
 #
-# $Id: progress.test,v 1.6 2006/05/26 19:57:20 drh Exp $
+# $Id: progress.test,v 1.7 2007/06/13 16:49:49 danielk1977 Exp $
 
 set testdir [file dirname $argv0]
 source $testdir/tester.tcl
@@ -97,8 +97,11 @@ do_test progress-1.2 {
   }
 } 10
 
-# Test that an active transaction remains active and not rolled back after the
-# progress query abandons a query. 
+# Test that an active transaction remains active and not rolled back 
+# after the progress query abandons a query. 
+#
+# UPDATE: It is now recognised that this is a sure route to database
+# corruption. So the transaction is rolled back.
 do_test progress-1.3 {
 
   db progress 0 ""
@@ -111,11 +114,13 @@ do_test progress-1.3 {
     INSERT INTO t1 VALUES(12)
   }
   db progress 0 ""
-  execsql COMMIT
+  catchsql COMMIT
+} {1 {cannot commit - no transaction is active}}
+do_test progress-1.3.1 {
   execsql {
     SELECT count(*) FROM t1
   }
-} 11
+} 10
 
 # Check that a value of 0 for N means no progress callback
 do_test progress-1.4 {
@@ -143,9 +148,9 @@ do_test progress-1.5 {
   db eval {
     SELECT sum(a) FROM t1
   }
-} {66}
+} {55}
 do_test progress-1.6 {
   set ::rx
-} {11}
+} {10}
 
 finish_test