Hey all,
As a follow up, the suggestion to change the write connection from
multithreaded to serialized mode seems to have done the trick. We set up some
automated testing and we now have approximately 300 runs in a row with no
corruption (as a control, with the multithreaded mode the
The pragmas I am using are just journal mode WAL and the add on pragma from
sqlcipher to set the key. I am using threads fairly heavily (or rather C# is
via Tasks and asynchronous ops), but here is the overall model:
Read connection (read only) shared between threads freely. I can pump this
On 30 Jun 2016, at 3:11pm, Jim Borden wrote:
> There were two instances of reported corruption today
Are you using any pragmas ? Are you using threads ? Are you using more than
one process in one program ?
Simon.
___
Hello all,
Sorry for the delay. It’s really hard to get this error to happen but I have
some more relevant information.
I observed a read only connection (there are two connections open to the DB,
one for reading only and one for writing / internal reading) suddenly start
returning error
On Thu, Jun 23, 2016 at 6:13 PM, Jim Borden wrote:
> The library will be happily running along and then suddenly a SELECT
> statement will return error code 26 upon step.
Error code 26 is SQLITE_NOTADB. That only happens when SQLite is
reading the 100-byte header at
On 23 Jun 2016, at 11:13pm, Jim Borden wrote:
> From what I have read, error 11 is extremely hard to cause through library
> usage alone. The key offences seem to be:
>
> 1) Using two versions of SQLite at once in an application
> 2) Bad OS file locking
> 3) A rogue
I’m having an issue with a library I am writing. This has not happened before
in the 1 ½ years I have been developing the library, but for some reason now
it’s rearing its ugly head from time to time. The library will be happily
running along and then suddenly a SELECT statement will return
7 matches
Mail list logo