[sqlite] UPDATE/open/close blocked while executing SELECT

Hi, I am using SQLite C amalgamation version 3.08.11.01 compiled for Multi Threading Mode and using WAL Journal Mode. Sometimes I need to execute a SELECT statement which takes a very long time to complete. I realized that during that time other functions are blocked for a significant amount

[sqlite] UPDATE/open/close blocked while executing SELECT

, April 18, 2016 2:47 PM To: SQLite mailing list Subject: Re: [sqlite] UPDATE/open/close blocked while executing SELECT > Le 18 avr. 2016 ? 14:17, Detlef Golze a ?crit : > > Hi, > > I am using SQLite C amalgamation version 3.08.11.01 compiled for Multi > Threading Mode and

[sqlite] UPDATE/open/close blocked while executing SELECT

> Detlef Golze wrote: > > I attach the database with the URI option cache=shared. > > This makes all threads share a single connection. Don't do it. > > > Regards, > Clemens That was indeed the problem. During my initial tests this option provided the best perform

[sqlite] INTEGRITY_CHECK consumes entire system memory

Hi, please check if this helps: http://serverfault.com/questions/325277/windows-server-2008-r2-metafile-ram-usage The provided script (setfc.ps1) did help for us and thus we implemented the suggested SetSystemFileCacheSize calls in our application. Regards, dg. -Original Message-

Re: [sqlite] Bug? Incorrect use of SQLITE_DEFAULT_CACHE_SIZE

Joe Mistachkin Sent: Monday, February 20, 2017 10:02 AM To: 'SQLite mailing list' Subject: Re: [sqlite] Bug? Incorrect use of SQLITE_DEFAULT_CACHE_SIZE Detlef Golze wrote: > > SQLITE_DEFAULT_CACHE_SIZE is defined as page size if positive or > Kbyte if negative. > The SQLITE_DEFAULT_C

[sqlite] Bug? Incorrect use of SQLITE_DEFAULT_CACHE_SIZE

Hi, the following looks like an incorrect use of SQLITE_DEFAULT_CACHE_SIZE (amalgamation 3.17 starting at line 37963): /* * This is cache size used in the calculation of the initial size of the * Win32-specific heap. It cannot be negative. */ #ifndef SQLITE_WIN32_CACHE_SIZE # if

Re: [sqlite] Bug? Incorrect use of SQLITE_DEFAULT_CACHE_SIZE

use of SQLITE_DEFAULT_CACHE_SIZE Detlef Golze wrote: > > Changes carried forward from version 3.12.0 (2016-03-29): > Ah, right. I was reading the comments in the source code. I've checked-in some changes that should prevent integer overflows when very large val

[sqlite] Partial Index and Query Planner

Hi, suppose I have a partial index like that: CREATE INDEX MyIndex1 ON MyTable ( Value1 ) WHERE Value1<>0; As documented, the query planner only uses the index if the SELECT contains that exact same condition. According to .eqp with 3.12.1 the following statement indeed uses the index:

[sqlite] sqlite3_changes() using 64 bit counters?

Hi, is there a plan for sqlite3_changes() and sqlite3_total_changes() returning 64 bit values? SQLite supports far more rows than a signed 32 bit counter can store and I would feel more comfortable if I don't need to check for an overflow. Thank you, Detlef.

Re: [sqlite] sqlite3_changes() using 64 bit counters?

The maximal number of rows is 1e+13 (). I do have tables with more than 2^32 rows. Of course one should avoid making that large transactions, but it is possible. Regards, dg. -Original Message- From: sqlite-users

[sqlite] BEGIN IMMEDIATE fails with "cannot start a transaction within a transaction (1)" without nested transsactions

Hello, we have a situation where "BEGIN IMMEDIATE" unexpectedly returns SQLITE_ERROR with message "cannot start a transaction within a transaction (1)". We have multiple threads running which repeatedly do the following: BEGIN IMMEDIATE INSERT ... INSERT ... COMMIT This

Re: [sqlite] sqlite3_get_autocommit() changes value when sqlite3_step() returns SQLITE_BUSY

This also fixes the problem I mentioned here: https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg108340.html (BEGIN IMMEDIATE fails with "cannot start a transaction within a transaction (1)" without nested transsactions) Thanks, Detlef. -Ursprüngliche Nachricht- Von:

Re: [sqlite] Feature request: more robust handling of invalid UTF-16 data

I want to second that. This leads to the situation that data is accepted by the database but there is no way to read that data back or more precisely I get the wrong (i.e. different) data back. I didn't check the suggested patch, but I don't believe it will work in all cases. I'd rather prefer