On 2018/07/05 8:51 PM, dmp wrote:
Given:
SELECT STRFTIME('%s', '2018-01-01');
1514764800
SELECT STRFTIME('%s', '2017-01-01');
1483228800
CREATE TABLE date_types(
id INTEGER PRIMARY KEY,
date_type DATE
);
INSERT INTO "date_types" ("id", "date_type") VALUES(1, 1514764800);
INSERT INTO
In section 2, the docs read:
The default is:
RANGE BETWEEN UNBOUNDED PRECEDING TO CURRENT ROW
I believe it should read instead:
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
You have to make everything the same type, either numeric or text. When
possible though you want to do your conversions on your input constant(s), and
not on the stored values. That way you can use an index on the stored value.
sqlite> create index date_type_index on date_types(date_type);
>SELECT CAST((SELECT (julianday('now', 'localtime') -
>julianday('1970-01-01'))*24*60*60*1000) AS INTEGER);
Are you sure you want to be mixing up timezones?
julianday('1970-01-01') returns the julianday timestamp for 1970-01-01 00:00:00
GMT
julianday('now', 'localtime') returns the julianday
Correct.
You have stored integer Unix Epoch timestamps. You cannot do "string" searches
on integers (at least not ones like what you have asked for, which involves
conversion of an integer representing a Unix Epoch offset to an ISO-8601
string, not to an ordinary "string representation of
Given:
SELECT STRFTIME('%s', '2018-01-01');
1514764800
SELECT STRFTIME('%s', '2017-01-01');
1483228800
CREATE TABLE date_types(
id INTEGER PRIMARY KEY,
date_type DATE
);
INSERT INTO "date_types" ("id", "date_type") VALUES(1, 1514764800);
INSERT INTO "date_types" ("id", "date_type")
Hello all,
I am working on a project involving the Python SQLite3 API for SQLite (a
compile cache system), and I have started running into "database locked"
problems on the Windows 7 Pro machines some of the instances will run on;
the Windows 10 instances works without any problems.
The
Hi, Simon,
On Thu, Jul 5, 2018 at 11:45 AM, Simon Slavin wrote:
> On 5 Jul 2018, at 4:51pm, Igor Korot wrote:
>
>> Is there a way to get which command was executed?
>> Or which table was added/changed/dropped?
>
> There is no reason for SQLite to record the information you want. If a
>
On 5 Jul 2018, at 4:51pm, Igor Korot wrote:
> Is there a way to get which command was executed?
> Or which table was added/changed/dropped?
There is no reason for SQLite to record the information you want. If a
connection you have no control over changes your schema you can't do anything
Can't you just use IFNULL to assign a default value?
CASE IFNULL( x, -999 )
WHEN 1 THEN 11
WHEN 2 THEN 22
WHEN 3 THEN 33
WHEN 4 THEN 44
WHEN -999 THEN 55
ELSE 66
END
On 5 July 2018 at 11:35, R Smith wrote:
> On 2018/07/05 8:44 AM, Simon Slavin wrote:
>
>> On 5 Jul 2018, at 7:30am,
Hi,
On Tue, Jun 19, 2018 at 1:56 PM, Richard Hipp wrote:
> On 6/19/18, Igor Korot wrote:
>> Hi, Wout,
>>
>> On Tue, Jun 19, 2018 at 1:31 PM, Wout Mertens
>> wrote:
>>> you can query the table with
>>> https://www.sqlite.org/pragma.html#pragma_table_info
>>
>> Let me give you a scenario:
>>
>>
I believe this trigger below should work for you. If you insert with the
sequence number null, then it'll make it one more than the current max, or 1 if
the table's empty. If you explicitly give it a sequence number then the trigger
doesn't fire and your specific sequence number either goes in
On 2018/07/05 8:44 AM, Simon Slavin wrote:
On 5 Jul 2018, at 7:30am, Clemens Ladisch wrote:
The expression "x = x" will fail for NULL, but succeed for everything
else. So you can use that to implement a "not-NULL ELSE"
Wow. That has to be the most counter-intuitive feature of SQLite. I
On Thursday, 5 July, 2018 00:57, Donald Shepherd :
>On Thu, 5 Jul 2018 at 16:45, Simon Slavin >wrote:
>> On 5 Jul 2018, at 7:30am, Clemens Ladisch >wrote:
>>> The expression "x = x" will fail for NULL, but succeed for
>>> everything else. So you can use that to implement a
>>> "not-NULL
On Thu, 5 Jul 2018 at 16:45, Simon Slavin wrote:
> On 5 Jul 2018, at 7:30am, Clemens Ladisch wrote:
>
> > The expression "x = x" will fail for NULL, but succeed for everything
> > else. So you can use that to implement a "not-NULL ELSE"
>
> Wow. That has to be the most counter-intuitive
On 5 Jul 2018, at 7:30am, Clemens Ladisch wrote:
> The expression "x = x" will fail for NULL, but succeed for everything
> else. So you can use that to implement a "not-NULL ELSE"
Wow. That has to be the most counter-intuitive feature of SQLite. I
understand why it works, but I still don't
Andy Goth wrote:
> The expression "x = NULL" is meaningless since it will always evaluate
> to NULL, which CASE interprets as untruth, hence "WHEN NULL THEN" will
> never accomplish anything.
> [...]
> So I'm wondering: can we do better?
The expression "x = x" will fail for NULL, but succeed for
17 matches
Mail list logo
