"Mark Brown" <[EMAIL PROTECTED]> wrote: > Thanks for the quick reply. Unfortunately, we are developing code > on the vxWorks platform, so I don't think sample code would be of > use. We have seen the problem for some time now...at least from > 3.3.12.
The logic in SQLite that handles cache synchronization was reworked in version 3.3.14. If you have been seeing the problem since 3.3.12, that suggests an application problem or possible a bug in your OS interface layer, not in the core SQLite. > The submitter of the ticket appears to have the exact same > scenario as us. Hopefully he can submit same sample code > that will help you track down the problem. As I pointed out in comments on the #2458 ticket, I can think of countless bugs in the application that can produce the same symptoms. There is no guarantee that this is an SQLite problem. And, in fact, until I have some evidence to the contrary, I'm working under the theory that this is an application bug not an SQLite bug. > > Would there be any diagnostics (i.e. printfs) that I could > enable that might be of use? > Bytes 24-27 of the database file contain a counter that is incremented every time the database file changes. A change in that counter is what triggers a cache flush. You might consider instrumenting your OS interface layer and making sure those bytes really are being read at the beginning of every transaction and written at the end of every transaction. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
