To correctly determine what SQLite is asking of your xUpdate routine requires
looking at argc, argv[0] and possibly argv[1] (if argc > 1).
You did not state your argc and argv[0] values, so looking at the documentation
would suggest that SQLite is actually asking for an INSERT into a WITHOUT ROW
In applications dates/times are input, dates/times are output.
Commonly the storage format of dates/times is of no concern.
More effort is often spent on time zone display and input, which is an
application issue rather than a data store issue. (e.g. fossil)
All one *needs* is database functions to
On Sunday, 11 August, 2019 16:02, Richard Damon
wrote:
>On 8/11/19 4:21 PM, Thomas Kurz wrote:
>>> I do understand the value of having date/time types in SQLite, but
>>> it is not easy to do while retaining backward compatibility.
I do not see any value in having a date/time type is SQLite.
On 11 Aug 2019, at 11:51pm, Thomas Kurz wrote:
> I don't see a huge problem here. Does the database file have a version number
> indicating which version the file has been created with? If so, newer SQLite
> libraries could easily emulate the old-style behavior by just checking this
> version
On Sunday, 11 August, 2019 07:45, Gabor Grothendieck
wrote:
>R supports Date and POSIXct (date/time) classes which are represented
>internally as days and seconds since the UNIX Epoch respectively;
>however, due to the class it knows to display and manipulate them as
>dates and datetimes rather
> The issue for something like a data-time field is how would you indicate
that a field is a data-time field. Due to backwards compatibility it
can't use the term data or time to trigger that use, as existing
applications use that and expect a different result, based on published
and promised rules
On 8/11/19 4:21 PM, Thomas Kurz wrote:
>> I do understand the value of having date/time types in SQLite, but it is not
>> easy to do while retaining backward compatibility. It'll have to wait for
>> SQLite4 or something.
> Actually I do not really understand the point about backward compatibilit
> I do understand the value of having date/time types in SQLite, but it is not
> easy to do while retaining backward compatibility. It'll have to wait for
> SQLite4 or something.
Actually I do not really understand the point about backward compatibility.
Many very useful suggestions are reject
On Sunday, 11 August, 2019 10:31, test user
wrote:
>By FFI I mean any of the public SQLite C functions exported from via
>FFI.
>Ok thanks, this makes sense the error callback is called whilst
>SQLite is executing exec/step.
>Do I need on callback per thread?
No, the callback configuration is
By FFI I mean any of the public SQLite C functions exported from via FFI.
Ok thanks, this makes sense the error callback is called whilst SQLite is
executing exec/step.
Do I need on callback per thread?
On Sun, Aug 11, 2019 at 4:31 PM Clemens Ladisch wrote:
> test user wrote:
> > The error log
test user wrote:
> The error log takes a callback which is called when an error occurs from
> any SQLite FFI function:
What exactly do you mean with "FFI"? You did not mention any other language.
> How does this interrupt my program whilst its running?
As a library, SQLite is part of your progr
Actually sqldf has multiple heuristics and the one you suggested is
already one of them
(except for minor differences in syntax) but this has the disadvantage
that the user must
specify classes whereas if the user simply uses any of the other backends
they don't have to.
On Sun, Aug 11, 2019 at 1
On 11 Aug 2019, at 2:45pm, Gabor Grothendieck wrote:
> R supports Date and POSIXct (date/time) classes which are represented
> internally as days and seconds since the UNIX Epoch respectively;
> however, due to the class it knows to display and manipulate them as
> dates and datetimes rather than
It's really useful that SQLite now supports window operations as that was
one of the key features that R users needed to do many manipulations
using SQLite.
From the perspective of the R language there is really one
particularly key feature left that prevents some users from easily
using SQLite in
Hello,
The error log takes a callback which is called when an error occurs from
any SQLite FFI function:
https://www.sqlite.org/errlog.html
How does this interrupt my program whilst its running? If my program is
busy, does it wait until the current function has completed and the process
is idle?
Hi everyone,
since my below issue looks like a bug, can we please file a ticket for it? I
understand that I cannot file the ticket myself and this mailing list is the
preferred way of asking to create a ticket on behalf of the reporter. I hope
that this is still correct.
Thank you and all the
16 matches
Mail list logo
