On the plus side they come out equal, so apart from neatness of the display,
all's good.
Interesting how the auto EQP output shows up in the .dump output. But at least
it starts with -- so won't harm anything.
SQLite version 3.18.0 2017-03-28 18:48:43
Enter ".help" for usage hints.
Connected to
In a previous message I suggest that behaviour under macOS changed between
SQLite 3.16.0 and SQLite 3.18.0. I then received information from a lurker who
uses Windows 7:
SQLite version 3.17.0 2017-02-13 16:02:40
INSERT INTO "xxx" VALUES(1.23);
…
SQLite version 3.18.0 2017-03-28 18:48:43
> Le 3 mai 2017 à 19:44, Tim Streater a écrit :
>
>> Would there be a cheap way for SQLite to log some more user-realm context
>> about these?
>> Maybe simply emitting a second call to the log function right after these
>> messages code 284 where the third parameter (msg)
On 3 May 2017, at 18:16, Olivier Mascia wrote:
> Would there be a cheap way for SQLite to log some more user-realm context
> about these?
> Maybe simply emitting a second call to the log function right after these
> messages code 284 where the third parameter (msg) would simply
> Le 3 mai 2017 à 18:46, Richard Hipp a écrit :
>
> On 5/3/17, Olivier Mascia wrote:
>> automatic index on sqlite_sq_25FA4563E0(ID) (284)
>> ...
>>
>> I guess they mean SQLite decided to build some temporary index for some
>> query execution, just
> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
> Behalf Of Simon Slavin
> Sent: Wednesday, May 03, 2017 12:30 PM
> To: SQLite mailing list
> Subject: Re: [sqlite] .DUMP displays floats differently
On 5/3/17, Olivier Mascia wrote:
> automatic index on sqlite_sq_25FA4563E0(ID) (284)
> ...
>
> I guess they mean SQLite decided to build some temporary index for some
> query execution, just as for the first case. But here the table itself looks
> like internal and
On 3 May 2017, at 3:40pm, Scott Robison wrote:
> On May 3, 2017 8:07 AM, "Tony Papadimitriou" wrote:
>
>> While trying to search/replace some text from an SQLite3 dump I noticed
>> that, unfortunately, .DUMP does not produce the exact same numbers as a
Dear,
On such a log line as:
automatic index on REMINDER(USER_LOGON) (284)
I understand what it means and what I might want to do (or not).
Though what should I understand from line like these:
automatic index on sqlite_sq_25FA456860(ID) (284)
automatic index on
On May 3, 2017 8:07 AM, "Tony Papadimitriou" wrote:
While trying to search/replace some text from an SQLite3 dump I noticed
that, unfortunately, .DUMP does not produce the exact same numbers as a
plain SELECT on the same values.
I know all about expected floating point
While trying to search/replace some text from an SQLite3 dump I noticed that,
unfortunately, .DUMP does not produce the exact same numbers as a plain SELECT
on the same values.
I know all about expected floating point inaccuracies, but I don’t see why it
should matter in this case as we have
2017-05-03 10:56 GMT+02:00 XIAO DAI :
> I have compiled SQLite v3.15.2 with the functions
> "sqlite3_user_authenticate, it runs well, for all the versions > 3.15.2, I
> can add the logins into the database, but sqlite(shell.c) does NOT ask for
> the authentication.
>
From
Hello,
I have compiled SQLite v3.15.2 with the functions "sqlite3_user_authenticate,
it runs well, for all the versions > 3.15.2, I can add the logins into the
database, but sqlite(shell.c) does NOT ask for the authentication.
Sorry for my poor english
sincerely
Xiao DAI
Ingénieur BE
FYI. I proposed a portable solution for a responsive interprocess work
queue within SQLite without using native IPC less than 2 weeks ago on this
very board. [See Dori the forgetful fish.]
https://www.mail-archive.com/sqlite-users@mailinglists.
sqlite.org/msg102741.html
DB reader(s) block/poll
14 matches
Mail list logo