On Fri, Nov 9, 2018 at 8:26 AM Simon Slavin wrote:
> On 9 Nov 2018, at 7:11am, Hick Gunter wrote:
> > Foreign keys are ignored by default and need to be explicitly enabled. I
> would expect this to include everything that relates to foreign keys.
> > I've casually discovered that the behavior of
On 9 Nov 2018, at 7:11am, Hick Gunter wrote:
> Foreign keys are ignored by default and need to be explicitly enabled. I
> would expect this to include everything that relates to foreign keys.
>
> -Ursprüngliche Nachricht-
>
> I've casually discovered that the behavior of ALTER TABLE RE
Foreign keys are ignored by default and need to be explicitly enabled. I would
expect this to include everything that relates to foreign keys.
-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
Auftrag von a.furi...@lqt.it
Gesendet: Donne
On 11/8/18, J. King wrote:
> On 2018-11-08 16:05:11, "Richard Hipp" wrote:
>
>>In case you are not following the ticket at
>>https://www.sqlite.org/src/tktview/787fa716be3a7f650cac1b1413f12f95f5e7639d,
>>we have simplified the test case to the following:
>>
>
> Richard,
> My mail client appears t
On 2018-11-08 16:05:11, "Richard Hipp" wrote:
In case you are not following the ticket at
https://www.sqlite.org/src/tktview/787fa716be3a7f650cac1b1413f12f95f5e7639d,
we have simplified the test case to the following:
Richard,
My mail client appears to have exposed a bug in Fossil. In includ
In case you are not following the ticket at
https://www.sqlite.org/src/tktview/787fa716be3a7f650cac1b1413f12f95f5e7639d,
we have simplified the test case to the following:
CREATE TABLE t5(a, b, c, d);
CREATE INDEX t5a ON t5(a);
CREATE INDEX t5b ON t5(b);
CREATE TABLE t6(e);
INSERT INTO t6 VALUES(1
Hallo,
I've casually discovered that the behavior of ALTER TABLE RENAME TO
(versione 3.25.x) seems to be affected by an odd glitch; FOREIGN KEY
constraints are updated as expected only when PRAGMA foreign_keys=1,
otherwise they are just ignored.
example (common part)
-
CREATE
Hello,
Without me knowing if it is related to your problem, I wonder what's the intent
here?
> SELECT `artists`.*
> FROM `artists`
> INNER JOIN `artists` AS 'b' ON (`b`.`id` = `artists`.`id`)
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
__
This crashes both my self-compiled version of the CLI _and_ the pre-compiled
one on Windows as well.
SQLite: 3.25.2
Windows 7
-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Jeremy Evans
Sent: Wednesday, November 07, 2018 7:36 PM
I wonder if this should be considered a bug, or if should be better
documented?
On Thu, Nov 8, 2018 at 9:57 AM 畑宏和 wrote:
> Thanks for your reply!
> My script's select-stmt do not include where.
> When I add 'where true', syntax error does not occur.
>
> Thanks!
>
> 2018年11月7日(水) 19:44、Richard H
Thanks for your reply!
My script's select-stmt do not include where.
When I add 'where true', syntax error does not occur.
Thanks!
2018年11月7日(水) 19:44、Richard Hipp さん（d...@sqlite.org）のメッセージ:
> On 11/6/18, 畑宏和 wrote:
> > Hi, I have a question.
> >
> > We can use upsert after v3.24.0.
> >
> > Doc
The following SQL causes a segmentation fault on:
* OpenBSD -current (3.25.1 and 3.25.3)
* MacOS 10.14 (3.25.2)
No segmentation fault using the precompiled Windows binary, though.
CREATE TABLE `artists` (
`id` integer NOT NULL PRIMARY KEY AUTOINCREMENT,
`name` varchar(255)
);
CREATE TABLE `a
12 matches
Mail list logo
