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
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
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
>
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
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
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
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.
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
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
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
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.
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
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
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
> 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
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
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.
>
>
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
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
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 ";
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
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
22 matches
Mail list logo