Closing the handle before going to sleep sounds like a really sensible thing to do which I hadn't heard of before, I will definitely try that!
Thanks for the quick responses from you all, Serena. On Tue, Oct 5, 2010 at 1:16 PM, Black, Michael (IS) <michael.bla...@ngc.com>wrote: > Could this also be because you never closed the database handle? So Sqlite > thinks it's still open? First time you get an errror do an sqlite3_close() > on the old handle. That may solve your problem. > > Next thing, you should register your app to receive the PBT_APMSUSPEND < > http://msdn.microsoft.com/en-us/library/aa372721(v=VS.85).aspx> event so > you can close the db handle before the system goes to sleep (you have two > seconds to do so -- you may need SetThreadExecutionState if you need > longer). > > Other option would be to only open the database when you need to and use > the SetThreadExecutionstate while you have it open. That will keep the > system from sleeping while it's busy. > > > Michael D. Black > Senior Scientist > Advanced Analytics Directorate > Northrop Grumman Information Systems > > > ________________________________ > > From: sqlite-users-boun...@sqlite.org on behalf of Drake Wilson > Sent: Tue 10/5/2010 5:59 AM > To: General Discussion of SQLite Database > Subject: EXTERNAL:Re: [sqlite] disk IO error after windows resumes from > sleep > > > > Quoth Serena Lien <serenal...@gmail.com>, on 2010-10-05 11:46:18 +0100: > > On a windows vista/win7 machine or a laptop which goes into sleep mode, > when > > it resumes and the application tries to open a database on a networked > > drive, the open function returns SQLITE_CANTOPEN and SQLITE_IOERR. I > don't > > have a problem with this, if the OS has lost access to the network I can > > imagine SQLITE_IOERR is quite valid. My question is, is there any way to > > recover now from this error without forcing my application to exit and > > restart? Any number of retries using sqlite3_open_v2 always continue to > fail > > with SQLITE_IOERR. > > > > It is possible the response will be "not sqlite's problem", but I would > > appreciate any advice anyone has to give, > > I would say that unless SQLite is returning that error in unwarranted > cases, this is really an application-level error recovery problem. > What do you mean by "always continue to fail"? Is this the case even > after you have verified that the desired file is accessible? Are you > delaying retries at all? > > If the IOERR return code is truthfully signaling inability to access > the file, then if this is an interactive application, you might signal > the user to request a retry later. If it's a batch process, you might > schedule a retry for later. If there's some alternative way of > accessing the database or operating at reduced functionality without > it, you might try that. It's hard to be more specific without knowing > what kind of application is being developed. > > ---> Drake Wilson > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
