Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-27 Thread Barry Smith
Quite strange that Prepare() makes a difference. The system.data.sqlite documentation states that Prepare() does nothing, and a code inspection of the system.data.sqlite source shows that it does nothing but check that the command hasn't been disposed, and that the connection is still valid

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-27 Thread Roberts, Barry (FINTL)
Hi, I am aware of the sqlite FAQ, and especially the comments regarding file systems. We only ever use NTFS file system, and never have any FAT or FAT32 file systems. Given that the old 1.0.80.0 driver is totally stable, and the newer one is not, on the same exact hardware, I do not think the

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-26 Thread Barry Smith
> On 26 Sep 2017, at 12:14 am, Clemens Ladisch wrote: > > Roberts, Barry (FINTL) wrote: >> As per my original post, all C# access code is making extensive use of >> "using" statements. However we do obviously rely on the connection pool >> being thread safe, because many

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-26 Thread Clemens Ladisch
Roberts, Barry (FINTL) wrote: > As per my original post, all C# access code is making extensive use of > "using" statements. However we do obviously rely on the connection pool > being thread safe, because many threads are writing to different > databases (connections) concurrently. > > There is

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-25 Thread Darko Volaric
If you're accessing a database concurrently from different processes then you may want to look at this: https://sqlite.org/faq.html#q5 as your file system may be causing you problems. > On Sep 25, 2017, at 11:09 AM, Roberts, Barry (FINTL)

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-25 Thread Roberts, Barry (FINTL)
Hi Clemens, As per my original post, all C# access code is making extensive use of "using" statements. However we do obviously rely on the connection pool being thread safe, because many threads are writing to different databases (connections) concurrently. There is no direct relationship

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-25 Thread Darko Volaric
That's not strictly true, it depends on the threading mode: https://sqlite.org/threadsafe.html It sounds like the driver is trying to manage concurrency on its own and failing. For the purposes of calling sqlite, if the library is used in the default

Re: [sqlite] ADO.NET driver upgrade puzzle

2017-09-25 Thread Clemens Ladisch
Roberts, Barry (FINTL) wrote: > The application is multi-threaded > > the system sometimes locks up, or marks one or more of the db3 as malformed. Sounds like a threading problem. You should not have more than one thread accessing the same connection concurrently. > Using (connection) > Open

[sqlite] ADO.NET driver upgrade puzzle

2017-09-25 Thread Roberts, Barry (FINTL)
Hi, We have a C# application which logs data in real-time to sqlite files. The application is multi-threaded, and typically logs 200-500 data streams simultaneously. The logging rate per stream is 1Hz to 1000Hz, depending on the type of data coming in. Each data stream is logged to its own db3