I've asked before about -mj. files that are left after using SQLite on a
Windows machine.  In every instance where this has happened, it has been
caused by some third party app (often virus scanners) that grab hold of the
file and cause the delete to fail.

But now I have a case where there is no such 3rd party app getting involved
(we're watching with SysInternal's FileMon which shows all file system
activity in real-time).  Out of desperation, I'm looking at SQLite source
and wondering about something I see.

In the 3.4.1 amalgamation, in vdbeCommit, the master journal file is
created, and deleted at the end or if there is an error.
But it looks like there is one case where it gets closed but not deleted and
I'm curious if this is a bug or there is a reason.  The code is:

    for(i=0; rc==SQLITE_OK && i<db->nDb; i++){ 
      Btree *pBt = db->aDb[i].pBt;
      if( pBt && sqlite3BtreeIsInTrans(pBt) ){
        rc = sqlite3BtreeCommitPhaseOne(pBt, zMaster);
      }
    }
    sqlite3OsClose(&master);
    if( rc!=SQLITE_OK ){
      sqliteFree(zMaster);
      return rc;
    }

I'm also wondering what might cause a commit to fail.  I'm assuming it could
be anything from bad SQL (ie a constraint not being met) to I/O errors.
Hopefully I'll get some log files that will give me more insight.

Thanks for any input.
Doug



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to