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. 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] -----------------------------------------------------------------------------
-- Joel Cochran
