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

Reply via email to