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
