When using MSVC to compile the SQLite library, several errors pop up about
differing linkage definitions of several session extension functions. These
functions are declared without the SQLITE_API macro, but are implemented with
it. MSVC does not like this and fails the compilation.
I have tes
On 11 May 2017, at 4:12pm, Bill Wade wrote:
> I'd say that "local file system" versus "remote file system" is really more
> of a shorthand for the requirement that low-level operations such as locks
> and reads behave the way that sqlite expects them to behave.
>
>
>
> In particular, locks on
I'd say that "local file system" versus "remote file system" is really more
of a shorthand for the requirement that low-level operations such as locks
and reads behave the way that sqlite expects them to behave.
In particular, locks on remote file systems are notorious for poor behavior.
If I
Thank you,
I think my issue was that I didn't know HAVING could use a non-aggregate
expression.
I'll do more reading tomorrow on that and bare columns in aggregate queries.
-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Dan Ken
On 05/12/2017 02:47 AM, David Raymond wrote:
My brain might just not be working right today. Would you be so kind as to give
an example for:
"Transfer any terms of the HAVING clause that use only columns mentioned in the
GROUP BY clause over to the WHERE clause for faster processing."
Say:
My brain might just not be working right today. Would you be so kind as to give
an example for:
"Transfer any terms of the HAVING clause that use only columns mentioned in the
GROUP BY clause over to the WHERE clause for faster processing."
?
Thanks
-Original Message-
From: sqlite-us
Richard Hipp wrote:
> On 5/11/17, Clemens Ladisch wrote:
>> Richard Hipp wrote:
>>> ** ^When a table is referenced by a [SELECT] but no column values are
>>> ** extracted from that table (for example in a query like
>>> ** "SELECT count(*) FROM tab") then the [SQLITE_READ] authorizer callback
>>>
SQLite version 3.19.0 will soon enter testing with a target release
date of 2017-05-25. If you have any issues or concerns, please bring
them up now.
Change log: https://sqlite.org/draft/releaselog/3_19_0.html
Snapshot: https://sqlite.org/download.html
Checklist: https://sqlite.org/chec
> Le 11 mai 2017 à 14:29, Richard Hipp a écrit :
>
> On 5/11/17, Gwendal Roué wrote:
>
>> 1. Existing callbacks that catch SQLITE_READ expect a non-NULL column
>>
>
> Very well. The behavior has been changed so that an SQLITE_READ with
> an empty-string column name, instead of a NULL column
On 5/11/17, Gwendal Roué wrote:
> 1. Existing callbacks that catch SQLITE_READ expect a non-NULL column
>
Very well. The behavior has been changed so that an SQLITE_READ with
an empty-string column name, instead of a NULL column name, is invoked
when a table referenced but not used. Also, the
AFAIK The sqlite logging function already includes the OS error message for
i/o errors, so you'll have it there in the log already. It would be
difficult to capture that and plumb it back to the callsite though, since
the logging function provides you with zero context as to which connection
is res
On 5/11/17, Clemens Ladisch wrote:
> Richard Hipp wrote:
>> ** ^When a table is referenced by a [SELECT] but no column values are
>> ** extracted from that table (for example in a query like
>> ** "SELECT count(*) FROM tab") then the [SQLITE_READ] authorizer callback
>> ** is invoked once for that
Richard Hipp wrote:
> ** ^When a table is referenced by a [SELECT] but no column values are
> ** extracted from that table (for example in a query like
> ** "SELECT count(*) FROM tab") then the [SQLITE_READ] authorizer callback
> ** is invoked once for that table with a NULL column name.
The docum
13 matches
Mail list logo
