Re: [sqlite] Help with confirming a couple of error traces

2017-01-31 Thread Richard Hipp
On 1/31/17, Shaobo He wrote: > Hi there, > > My name is Shaobo He and I am a graduate student at University of Utah. I > am applying a couple of static analysis tools to C projects. The tools I am > using reports a few partial error traces about null pointer dereferences. I

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

2017-01-31 Thread dandl
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of James K. Lowden >>>Despite the fact that the Windows API is defined in terms of C, Microsoft >>>evidently and probably correctly has decided its market does not demand a >>>modern C compiler. The Microsoft

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

2017-01-31 Thread Scott Robison
On Jan 31, 2017 6:25 PM, "James K. Lowden" wrote: On Tue, 31 Jan 2017 15:50:08 -0800 Nathan Bossett wrote: > Since this is the sqlite users list and not the dev's list, can I ask > what your use case is that writing a thin wrapper around SQLITE >

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

2017-01-31 Thread James K. Lowden
On Tue, 31 Jan 2017 15:50:08 -0800 Nathan Bossett wrote: > Since this is the sqlite users list and not the dev's list, can I ask > what your use case is that writing a thin wrapper around SQLITE > doesn't solve your problem? I've encountered no problem compiling SQLite

Re: [sqlite] DELETE when DB is full

2017-01-31 Thread Simon Slavin
On 31 Jan 2017, at 10:40pm, Warren Young wrote: > On Jan 31, 2017, at 2:03 PM, Ward WIllats wrote: > >> the delete sometimes (very rarely) fails with a 13 "disk or database full" >> error. I assume because the purger is late to the party and it

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

2017-01-31 Thread Nathan Bossett
On Tue, Jan 31, 2017 at 11:48:10AM -0500, James K. Lowden wrote: > On Mon, 30 Jan 2017 13:32:46 -0700 > Scott Robison wrote: > > > Basing source on "ANSI C" (as much as possible) just gives you the > > biggest possible distribution / compatibility. > > Yes, but it also

[sqlite] Sqlite on C99/C11 (was: RE: BUG: Illegal initialization in icu.c : sqlite3IcuInit)

2017-01-31 Thread dandl
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of James K. Lowden Basing source on "ANSI C" (as much as possible) just gives you the biggest possible distribution / compatibility. >>> >>>Yes, but it also limits you to C as it stood 20 years ago.

[sqlite] Help with confirming a couple of error traces

2017-01-31 Thread Shaobo He
Hi there, My name is Shaobo He and I am a graduate student at University of Utah. I am applying a couple of static analysis tools to C projects. The tools I am using reports a few partial error traces about null pointer dereferences. I was wondering if you could help me to identify whether they

Re: [sqlite] DELETE when DB is full

2017-01-31 Thread Warren Young
On Jan 31, 2017, at 2:03 PM, Ward WIllats wrote: > > the delete sometimes (very rarely) fails with a 13 "disk or database full" > error. I assume because the purger is late to the party and it needs pages in > the WAL to be able to rollback if necessary. Is there an

Re: [sqlite] DELETE when DB is full

2017-01-31 Thread Richard Hipp
On 1/31/17, Ward WIllats wrote: > 1. The operational assumption (delete need pages) I've asserted here is > correct, and That is correct. While the delete is underway, you need to have both the old and new content of every modified database page stored on disk, in case

[sqlite] DELETE when DB is full

2017-01-31 Thread Ward WIllats
Hello. We have an embedded system out in the wild with a DB in WALL mode that we set a max_pages value on to keep its size constrained. The system is more or less a data logger. We run a "purger" thread at intervals to DELETE records when it discovers free space is running below a threshold.

Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection

2017-01-31 Thread Scott Robison
On Tue, Jan 31, 2017 at 12:15 PM, Jens Alfke wrote: > > > On Jan 31, 2017, at 9:39 AM, James K. Lowden > wrote: > > > > According the SQL standard, every SQL statement is atomic. SELECT has > > no beginning and no end: the results it returns

[sqlite] Request: Per-connection equivalent to SQLITE_CONFIG_LOG

2017-01-31 Thread Jens Alfke
Our library is registering a SQLITE_CONFIG_LOG callback* to log error messages. This can provide useful information about errors returned by SQLite. However, we’ve found a side effect that, since this callback is global, it gets called due to activity from other clients using SQLite in the same

Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection

2017-01-31 Thread Richard Hipp
On 1/31/17, Jens Alfke wrote: > > My immediate workaround (implemented last night) is to iterate over the > statement at the moment the query is run, saving all the rows in memory. Our > enumerator object then just reads and returns successive rows from that > list. That's

Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection

2017-01-31 Thread Jens Alfke
> On Jan 31, 2017, at 9:39 AM, James K. Lowden wrote: > > According the SQL standard, every SQL statement is atomic. SELECT has > no beginning and no end: the results it returns reflect the state of > the database as of the moment the statement was executed. If you

Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection

2017-01-31 Thread James K. Lowden
On Mon, 30 Jan 2017 19:29:40 -0800 Jens Alfke wrote: > if I iterate over the the rows in a table using sqlite3_step, and > update each row after it?s returned, Bad Stuff happens. Specifically, > my query is just getting the first row over and over and over again, > and the

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

2017-01-31 Thread Scott Robison
On Tue, Jan 31, 2017 at 9:48 AM, James K. Lowden wrote: > On Mon, 30 Jan 2017 13:32:46 -0700 > Scott Robison wrote: > > > Basing source on "ANSI C" (as much as possible) just gives you the > > biggest possible distribution / compatibility. > >

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

2017-01-31 Thread James K. Lowden
On Mon, 30 Jan 2017 13:32:46 -0700 Scott Robison wrote: > Basing source on "ANSI C" (as much as possible) just gives you the > biggest possible distribution / compatibility. Yes, but it also limits you to C as it stood 20 years ago. And counting. Is there no point at

Re: [sqlite] Does SQLite use field definitions?

2017-01-31 Thread Hick Gunter
Yes. See http://sqlite.org/lang_createtable.html for details. I also suggest you look at http://sqlite.org/datatype3.html too -Ursprüngliche Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Clyde Eisenbeis Gesendet: Dienstag, 31. Jänner

[sqlite] Does SQLite use field definitions?

2017-01-31 Thread Clyde Eisenbeis
In the past, when using Access as a database, I have specified field definitions. These field definitions have been used when creating a table. public const string stFIELD_DEFINITIONS = " fstPriority TEXT, fstInfo MEMO, fstDateCreated TEXT, fstDateModified TEXT, fiKeyID INTEGER PRIMARY KEY ";

Re: [sqlite] can't open db when path length extends 512 characters (on linux)

2017-01-31 Thread Rowan Worth
On 31 January 2017 at 17:32, Jan Nijtmans wrote: > 2017-01-30 19:37 GMT+01:00 Dan Kennedy: > > On 01/31/2017 12:48 AM, Nir Paz wrote: > >> Linux doesn't have that limit, my thought is to change the define of > >> MAX_PATHNAME, is there a better option? > > > > I don't

Re: [sqlite] can't open db when path length extends 512 characters (on linux)

2017-01-31 Thread Jan Nijtmans
2017-01-30 19:37 GMT+01:00 Dan Kennedy: > On 01/31/2017 12:48 AM, Nir Paz wrote: >> Linux doesn't have that limit, my thought is to change the define of >> MAX_PATHNAME, is there a better option? > > I don't think there is a better way to do that. Define MAX_PATHNAME to > something and see how it