Re: [sqlite] database locked on select

or 1 thread...or 6000 threads...makes no difference whatever. Unless you changed the default from SERIALIZED to something that does not apply. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original

Re: [sqlite] database locked on select

BTW why not to update all rows by single update query? 2018-05-27 20:30 GMT+02:00, Torsten Curdt : > I am doing a select, then iterate through the resultset and on each row > call update on that row. > I am using the golang driver and ran into the issue that on the update the >

Re: [sqlite] This is driving me nuts

Alternatively you can alloc physical memory using AWE mechanism. AWE requires SeLockMemoryPrivilege, so you may have to run the application on an administator account (or other account with sufficient rigths). When using AWE there is no need to increase working set size because AWE pages are not

Re: [sqlite] database locked on select

There is no multi threading. Just a single thread and only one connection/handle. While iterating through the resultset I am also trying to execute an update for every row. Along the lines of: resultset = db.exec(`select`) foreach row in resultset { db.exec(`update`) } I don't want to

Re: [sqlite] database locked on select

On 27 May 2018, at 11:49pm, Deon Brewis wrote: > By one connection doing SELECT and UPDATE, do you mean multi-threaded mode > and using the connection from 2 threads? A connection cannot lock the database against itself. If you are doing two operations with one connection,

Re: [sqlite] database locked on select

By one connection doing SELECT and UPDATE, do you mean multi-threaded mode and using the connection from 2 threads? - Deon -Original Message- From: sqlite-users On Behalf Of Simon Slavin Sent: Sunday, May 27, 2018 3:39 PM To: SQLite

Re: [sqlite] database locked on select

On 27 May 2018, at 7:30pm, Torsten Curdt wrote: > I am doing a select, then iterate through the resultset and on each row > call update on that row. > I am using the golang driver and ran into the issue that on the update the > database is still locked from the select. Are you

Re: [sqlite] This is driving me nuts

Firstly you have to enable SeIncreaseWorkingSetPrivilege - to do this you may use the function enableIncreaseWorkingSetPrivilege listed below, it should return 0 on success - then you can use SetProcessWorkingSetSize(GetCurrentProcess(), *NewMinSize*, *NewMaxSize*); Working set sizes must be

[sqlite] database locked on select

I am doing a select, then iterate through the resultset and on each row call update on that row. I am using the golang driver and ran into the issue that on the update the database is still locked from the select. https://github.com/mattn/go-sqlite3/issues/569 I have read

[sqlite] SQLite creating disk file for memory db

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 = new

Re: [sqlite] This is driving me nuts

Starting to mess about with windows handles and pages I’ve never heard of is beyond my pain threshold Abrozy. Thanks anyway. From: sqlite-users on behalf of Abroży Nieprzełoży

Re: [sqlite] This is driving me nuts

I think you can experiment with changing the the working set size limits and see what the effect will be. https://msdn.microsoft.com/en-us/library/cc441804 2018-05-27 17:09 GMT+02:00, curmudgeon : > It seems the array was being optimised away. I had to initialise every

Re: [sqlite] This is driving me nuts

It seems the array was being optimised away. I had to initialise every value to get the OS to claim the RAM. Once I did that the timings for the array were on a par with the vector with the second pass being slower than the first. While that clears up that part of the mystery I'm no closer to a

Re: [sqlite] This is driving me nuts

Strange. I repeated the test with v an int64 array (see below) however the FreeMB() doesn’t change. Both Memi’s return pretty much the value of Mem ??? for (int i=0; i<2; i++) { v=new int64_t[Size[i]]; int64_t Memi=FreeMBs();

Re: [sqlite] This is driving me nuts

I’ve changed the app to populate v with the query result and noted the free ram before and after each resize. I’m hoping that addresses some of the concerns re compiler optimisations even if it doesn’t supply any real answers? Results were similar to before. #include #include #pragma hdrstop