On Wednesday, 30 October, 2019 16:33, mailing lists
wrote:
>I face the following issue:
>1) SQLite has been compiled with SQLITE_THREADSAFE=1 and
>SQLITE_DEFAULT_SYNCHRONOUS=3
>2) I am opening in a thread a new database (standard journal mode) and
>creating some tables, indices etc. (explicit
On 30 Oct 2019, at 10:33pm, mailing lists wrote:
> In this second thread (step (3)) I get an SQLITE_ERROR in sqlite3_prepare. I
> actually expected an SQLITE_BUSY error. Remark: as step (2) is a transaction
> no tables exist when step (3) starts execution.
>
> Is my understanding correct that
Hi,
I face the following issue:
1) SQLite has been compiled with SQLITE_THREADSAFE=1 and
SQLITE_DEFAULT_SYNCHRONOUS=3
2) I am opening in a thread a new database (standard journal mode) and creating
some tables, indices etc. (explicit transaction)
3) while creating the database a new database
On 2019-10-30 12:52 p.m., Keith Medcalf wrote:
On Wednesday, 30 October, 2019 13:23, Darren Duncan
wrote:
On 2019-10-30 12:02 p.m., Simon Slavin wrote:
On 30 Oct 2019, at 6:56pm, Darren Duncan wrote:
"Generated columns may not be used as part of the PRIMARY KEY. (Future
versions of
On Wednesday, 30 October, 2019 13:23, Darren Duncan
wrote:
>On 2019-10-30 12:02 p.m., Simon Slavin wrote:
>> On 30 Oct 2019, at 6:56pm, Darren Duncan wrote:
>>> "Generated columns may not be used as part of the PRIMARY KEY. (Future
>>> versions of SQLite might relax this constraint for
On 2019-10-30 12:02 p.m., Simon Slavin wrote:
On 30 Oct 2019, at 6:56pm, Darren Duncan wrote:
"Generated columns may not be used as part of the PRIMARY KEY. (Future versions of
SQLite might relax this constraint for STORED columns.)"
Replace with this:
"VIRTUAL generated columns may not be
The "not working" PureFunc detection is because the sqlite3NotPureFunc needs to
be checked in isDate if it is called with 0 arguments (in which a single
parameter of 'now' is assumed). This should fix the purefunc detection for
CHECK constraints and Indexes.
I still think that OP_Function
On 30 Oct 2019, at 6:56pm, Darren Duncan wrote:
> "Generated columns may not be used as part of the PRIMARY KEY. (Future
> versions of SQLite might relax this constraint for STORED columns.)"
>
> Replace with this:
>
> "VIRTUAL generated columns may not be used as part of the PRIMARY KEY."
On 2019-10-30 3:12 a.m., Richard Hipp wrote:
On 10/30/19, Darren Duncan wrote:
Ideally a PRIMARY KEY would have no restrictions that a UNIQUE constraint
lacks;
they are conceptually the same thing, a subset of the columns of the row
that
uniquely identifies the row in the table, and
On Wednesday, 30 October, 2019 06:41, Dominique Devienne
wrote:
>On Wed, Oct 30, 2019 at 11:26 AM Richard Hipp wrote:
>> On 10/29/19, Keith Medcalf wrote:
>> > Before you change anything, I think that is incorrect for the various
>> > datetime functions. I think they SHOULD be permitted
On October 30, 2019 9:58:20 a.m. EDT, Simon Slavin wrote:
>There are things you cannot split across different database files. For
>instance, you cannot declare a FOREIGN KEY that refers to a table in a
>different schema. Because SQLite can't be sure you'll have that schema
>available.
It's
"There's a limit, somewhere around ten, I think. Though you can increase it by
explicitly messing with limits and compilation options."
Default is 10, can be raised to 125.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
quot; you might use
SELECT customer_num, pre_tax_total, post_tax_total
FROM customers.invoices
WHERE invoice_date = "20191030"
There are things you cannot split across different database files. For
instance, you cannot declare a FOREIGN KEY that refers to a table in a
different
SQLite stores a single database in a single file.
According to the specific project requirements and due to the performance
concerns;
When working with large databases, is it possible to explicitly tell SQLite
not to store the whole DB in a single file and store different tables in
different
On Wed, Oct 30, 2019 at 11:26 AM Richard Hipp wrote:
> On 10/29/19, Keith Medcalf wrote:
> >
> > Before you change anything, I think that is incorrect for the various
> > datetime functions. I think they SHOULD be permitted in CHECK
> constraints
> > and in generated always columns, whether
On Wed, Oct 30, 2019 at 11:26 AM Richard Hipp wrote:
> On 10/29/19, Keith Medcalf wrote:
> >
> > Before you change anything, I think that is incorrect for the various
> > datetime functions. I think they SHOULD be permitted in CHECK
> constraints
> > and in generated always columns, whether
On 10/29/19, Keith Medcalf wrote:
>
> Before you change anything, I think that is incorrect for the various
> datetime functions. I think they SHOULD be permitted in CHECK constraints
> and in generated always columns, whether those are stored or virtual,
> whether or not parameters are given
On 10/30/19, Darren Duncan wrote:
>
> Ideally a PRIMARY KEY would have no restrictions that a UNIQUE constraint
> lacks;
> they are conceptually the same thing, a subset of the columns of the row
> that
> uniquely identifies the row in the table, and designating one as PRIMARY is
> completely
Would any kind soul be willing to explain the deterministic problem to me? I
can see that having now() in a virtual column would be a waste of time as the
virtual column value would change every time it was read but if it was being
stored then why not?
Also, I take it deterministic udf’s can
On Wed, Oct 30, 2019 at 8:32 AM Keith Medcalf wrote:
> On Tuesday, 29 October, 2019 23:05, Simon Slavin
> wrote:
> >On 30 Oct 2019, at 3:58am, Keith Medcalf wrote:
>
> >> Before you change anything, I think that is incorrect for the various
> >> datetime functions. I think they SHOULD be
I don’t think I did say that Marc. All I was saying was the ON didn’t have to
refer to the closest join.
select * from
tblA inner join tblB ON tblA.key = tblC key – no mention of tblB in ON
inner join tblC ON tblA.key = tblB.key; – no mention of tblC in ON
Normally that would be written
On Tuesday, 29 October, 2019 23:05, Simon Slavin wrote:
>On 30 Oct 2019, at 3:58am, Keith Medcalf wrote:
>> Before you change anything, I think that is incorrect for the various
>> datetime functions. I think they SHOULD be permitted in CHECK
>> constraints and in generated always columns,
22 matches
Mail list logo
