Barry Roberts wrote:
>
> Unfortunately the problem seems to be very difficult to replicate
reliably.
> Generally we are seeing around about a 5% failure rate at application
start.
> Any further info, ask away.
>
So far, I've been unable to reproduce the problematic behavior. I've added
some new
Hi Joe,
We are not using multiple app domains within a process.
Within the process where the errors are coming from we have
* N databases being accessed, typically between 5-100 separate databases
* Each database has a dedicated handler, to ensure we only ever invoke 1 writer
at a time to a
Nelson, Erik - 2, on Wednesday, May 15, 2019 11:04 AM, wrote...
>I maintained an in-house sqlite patch that did this for a number of years...
> just made the buffer a little bigger, printed something like
>
>" set tt.<==HERE"
>
>It was quite useful for helping application users self-serve their
R Smith, on Wednesday, May 15, 2019 11:06 AM, wrote...
>I of course forgot to remove 'p005' from the list (luckily David
>didn't!), so the query should have been:
>
>UPDATE t AS tx SET b = 'z' WHERE (a,idate) = (SELECT ty.a,MAX(ty.idate)
>FROM t AS ty WHERE ty.a = tx.a GROUP BY ty.a) AND a <
I of course forgot to remove 'p005' from the list (luckily David
didn't!), so the query should have been:
UPDATE t AS tx SET b = 'z' WHERE (a,idate) = (SELECT ty.a,MAX(ty.idate)
FROM t AS ty WHERE ty.a = tx.a GROUP BY ty.a) AND a < 'p005';
which works well here (picking the minimal route),
I maintained an in-house sqlite patch that did this for a number of years...
just made the buffer a little bigger, printed something like
" set tt.<==HERE"
It was quite useful for helping application users self-serve their own query
problems.
-Original Message-
From: sqlite-users
Table-valued syntax is your friend:
-- SQLite version 3.27.2 [ Release: 2019-02-25 ] on SQLitespeed
version 2.1.2.47.
--
create table t (n INTEGER PRIMARY KEY, a, b, c, d, e, idate);
David Raymond, on Wednesday, May 15, 2019 10:44 AM, wrote...
>When in doubt tinker. In this case it looks like it's the dot in "set tt.b =
>'z'"
> that it's complaining about. Its thinking is probably "if you're updating a
> table
> you can't set a field from a different table, so no qualified
When in doubt tinker. In this case it looks like it's the dot in "set tt.b =
'z'" that it's complaining about. Its thinking is probably "if you're updating
a table you can't set a field from a different table, so no qualified field
names there"
sqlite> UPDATE t as tt set tt.b = 'z' WHERE tt.a
Hi. I know this has been probably asked before by someone, but imagine the
following scenario:
create table t (n INTEGER PRIMARY KEY, a, b, c, d, e, idate);
insert into t (a, b, c, d, e, idate) values ('p001', 'a', 1, 'n', 4,
'2019-02-11');
insert into t (a, b, c, d, e, idate) values ('p002',
Hi Donald,
You are right. Sorry for not mentioning that. I was working on trunk and
using Linux. The bug has already been fixed:
https://www.sqlite.org/src/info/bc7d2c1656396bb4
Best,
Manuel
On Wed, May 15, 2019 at 3:13 PM Donald Griggs wrote:
> On Tue, May 14, 2019 at 10:18 AM Manuel Rigger
On Tue, May 14, 2019 at 10:18 AM Manuel Rigger
wrote:
> ...
>
> The query does not fetch a row. However, without the PRAGMA statement one
> row is fetched.
>
It probably helps the devs to specify the version you were testing.
For me, your example returns a single row of "1" in each case.
I'm
12 matches
Mail list logo