On Thu, Jan 27, 2011 at 10:22 AM, Dennis Suehr <den...@suehr.me.uk> wrote:
> > BEGIN TRANSACTION; > REPLACE INTO main.Table values (X,Y,Z); > REPLACE INTO attachedDbName.Table values (X,Y,Z); > COMMIT TRANSACTION; > > Using GDB, I put a breakpoint on the unixSync() function and then call my C > library function. > When the breakpoint gets hit, which it does 7 times until my C library > function runs to completion, I look for the existence of the Master > Journal, > which I find as expected in the same directory as my 'main' database. > > I then use 'rm' from a Bash shell to remove the attached DB's database file > and corresponding rollback journal. Then, I let my function run to > completion. Afterwards, I open up the 'main' database and examine the row > which I 'updated'. Unfortunately, it has been updated using the above > mentioned REPLACE statement. Deleting a database file out from under an active transaction does not interrupt that transaction. The "rm" command of unix does not delete files from the disk. It merely decrements their reference count. The files are not removed until the reference count reaches zero. While the transaction is in progress, SQLite has the file open and so the reference count is still 1 even after you do "rm". Then when SQLite closes the file, the reference count drops to zero and the file is removed. So really it is if there are transactions: The first transaction by SQLite completes exactly as it said it would. Then the second transaction (the "rm" command) deletes the ATTACHed database. If you want to interrupt a transaction, use the "kill -9" command on the SQLite process at one of the xSync calls. You'll find that the transaction will be rolled back. (We do extensive tests of that scenario before each release.) -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
