On Wed, 2007-04-18 at 10:06 -0400, Joel Cochran wrote: > OK, then I won't be worrying about Transactions for SELECT statements, it > doesn't really apply to our application. > > And some additionaly confirmation that Christian seems to have been right on > key: according to the problems reported at the System.Data.SQLite forums, > the problem is most likely due to the retaining of an ope Connection against > the database residing on removable media. When the system returns, the > "pointer" to the media is not guaranteed to work again. In other words, > every time the system shuts down, there is the potential for losing database > connectivity. The recommended solution is to move the database to internal > memory and use the CF card as a backup device.
If the win32 SetFilePointer() function fails (used to position the "pointer" at a given file offset, which SQLite does as part of a SELECT) SQLite assumes the reason is that the disk is full and returns SQLITE_FULL. This is probably what's happening here - SetFilePointer() is saying "the file-system is gone!" and SQLite is misinterpreting it. Probably SQLite should return SQLITE_IOERR instead. So why can't you just handle this in the application? Open and close the database connection when an SQLITE_FULL occurs. If the device is really shutting down (not starting up) then the second attempt to open will fail. Or just try every couple of seconds from that point on. Dan. > This also confirms why I can't replicate the problem in DEBUG: the device > never sleeps and the connection is never lost. > > I'll keep the list posted. > > Joel > > On 4/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > "Joel Cochran" <[EMAIL PROTECTED]> wrote: > > > should I be using > > > Transactions for SELECT statements? > > > > The only reason to use a transaction around SELECT statements > > is if you want to make sure that the database is not changed > > by another process in between consecutive SELECTs. > > > > It used to be the case that putting multiple SELECTs within > > a transaction would be slightly faster since doing so avoided > > a cache flush after each statement. But as of version 3.3.16 > > that cache flush is avoided regardless of whether or not > > transactions are used so performance should no longer be a > > factor. > > > > -- > > D. Richard Hipp <[EMAIL PROTECTED]> > > > > > > > > ----------------------------------------------------------------------------- > > To unsubscribe, send email to [EMAIL PROTECTED] > > > > ----------------------------------------------------------------------------- > > > > > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
