Re: [sqlite] [EXTERNAL] Re: database locked on select

Yes, manually buffering the resultset or buffering the updates is of course a possible workaround. But I would like to avoid that as much as possible. Another approach is to use limit/offset and then page through the resultset to control the amount of buffering needed. But this just feels like a

[sqlite] Final preparations for the release of System.Data.SQLite v1.0.109.0 have begun...

If you have any issues with the current trunk code, please report them via this mailing list (and/or by creating a ticket on "https://system.data.sqlite.org/;) prior to next Monday, June 4th. Thanks. -- Joe Mistachkin ___ sqlite-users mailing list

Re: [sqlite] [EXTERNAL] Re: database locked on select

On 28 May 2018, at 7:56pm, Torsten Curdt wrote: > Just to clarify: I have a single thread - so intermixing the stepping > through a resultset and doing an update requires WAL mode but should be > fine. Correct? Yes, this should work fine. Obviously, one thread is not going to be trying to do

Re: [sqlite] [EXTERNAL] Re: database locked on select

Just to clarify: I have a single thread - so intermixing the stepping through a resultset and doing an update requires WAL mode but should be fine. Correct? On Mon, May 28, 2018 at 11:01 AM Hick Gunter wrote: > As long as you are and remain in serialized mode, you can re-use the same >

Re: [sqlite] sqlite-users Digest, Vol 125, Issue 28

I asked the same question on stackoverflow and got the answer. Please have a look here - *https://stackoverflow.com/questions/50551624/sqlite-is-creating-a-disk-file-for-in-memory-db * Thanks for your

Re: [sqlite] sqlite-users Digest, Vol 125, Issue 28

> I tried to create a shareable in-memory database as per the documentation > provided on SQLite Site. But I end up finding the solution to the > problem. > > *Here is my code in C#*: > > > var connectionString = "Data > Source=sharedmemdb;Mode=Memory;Cache=Shared"; > > > using (var connection1

Re: [sqlite] This is driving me nuts

> why, when you've got 16 GB ram, does a 6.4 GB vector cause any problems? Jim, it was only 3.2 GB and it was compiled as 64 bit just in case you’re thinking 32. >Either this statement is wrong, or you've misattributed the 4 GB of memory. Rowan, I’ve misattributed. There’s a bug in the

Re: [sqlite] This is driving me nuts

On May 28, 2018, at 3:35 AM, Rowan Worth wrote: > > On 28 May 2018 at 17:29, x wrote: > >> I’ve just discovered the thread in the original app decreases the >> available memory by around 4 GB. Are they really that expensive? > > A thread itself is not

Re: [sqlite] This is driving me nuts

> why, when you've got 16 GB ram, does a 6.4 GB vector cause any problems? Architecturally, 4 GB is like the sound barrier -- you may get turbulence or a sonic boom. Because 4 GB was the limit for 32 bit word size any residual 32 bit code or 32 bit assumptions anywhere in the stack (or CPU)

Re: [sqlite] This is driving me nuts

On 28 May 2018 at 17:29, x wrote: > I’ve just discovered the thread in the original app decreases the > available memory by around 4 GB. Are they really that expensive? A thread itself is not expensive in terms of memory. > It has very little data of its own Either

Re: [sqlite] This is driving me nuts

I’ve just discovered the thread in the original app decreases the available memory by around 4 GB. Are they really that expensive? It has very little data of its own and just calls a function declared in the main thread. ___ sqlite-users mailing list

Re: [sqlite] This is driving me nuts

Many thanks for your efforts Abrozy. I will attempt to understand it later but the artificially created ‘Big’ table is something of a worst case scenario for me so I’m not sure it would be the best use of my time. If THEY can’t get memory management right who am I to think I will. I have to

Re: [sqlite] [EXTERNAL] Re: database locked on select

As long as you are and remain in serialized mode, you can re-use the same connection from different threads. If you can guarantee that each thread will have it's own, personal, connection, you may achieve a performance increase by using multithread mode. In single thread mode, all the checks

Re: [sqlite] [EXTERNAL] Re: database locked on select

Thanks for the suggestion but I feel that will just make things more complex. Right now I have one function that does it work and then decides whether to update or not. That way I would have to split that one function into two (new_data, needs_update) which is not so easy. Plus that also makes

Re: [sqlite] [EXTERNAL] Re: database locked on select

It is possible to bring an external resource into SQlite by writing user-defined functions and/or virtual tables. This would allow something like: UPDATE set () = new_data() where needs_update(); With the UDF returning 1 (TRUE) if the current row (identified by the arguments) needs an update

Re: [sqlite] database locked on select

I have to query an external resource for each row. Unfortunately nothing I can do in a single update query. Would mean keeping a lot of data manually in memory. On Mon, May 28, 2018 at 2:33 AM Abroży Nieprzełoży < abrozynieprzelozy314...@gmail.com> wrote: > BTW why not to update all rows by