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] -----------------------------------------------------------------------------