On 22 Jan 2017, at 2:40am, Keith Medcalf wrote:
> My suggestion would be to forgo the artificial relative position being
> computed by the application and replace it with the actual data used to
> determine the ordering, and add an appropriate ORDER BY when retrieving the
> data.
Or make the
On Saturday, 21 January, 2017 13:45 James K. Lowden
wrote:
> On Sat, 21 Jan 2017 19:33:06 +0200
> R Smith wrote:
> > UPDATE desktops SET indexNo = -indexNo - 1 WHERE indexNo >= X;
> > INSERT INTO desktops ... new row for indexNo X ... ;
> > UPDATE desktops SET indexNo = -indexNo WHERE indexN
On Sat, 21 Jan 2017 18:14:06 +
Simon Slavin wrote:
> It is a failure of atomicity in SQLite semantics.
>
> This is one I do feel is a bug in SQLite.
Thank you for your support. I feel it's important to understand it's a
bug, not a feature.
> I think I?ve seen other SQL implementations
On Sat, 21 Jan 2017 19:33:06 +0200
R Smith wrote:
> UPDATE desktops SET indexNo = -indexNo - 1 WHERE indexNo >= X;
> INSERT INTO desktops ... new row for indexNo X ... ;
> UPDATE desktops SET indexNo = -indexNo WHERE indexNo < 0;
unless
FOREIGN KEY indexNo references foo(bar)
or
On Sat, 21 Jan 2017 11:54:57 +0100, Cecil Westerhof
wrote:
>I have the following (work in progress) table:
>CREATE TABLE desktops(
>nameTEXTNOT NULL PRIMARY KEY,
>indexNo INTEGER NOT NULL UNIQUE,
>value TEXTNOT NULL UNIQUE,
>waitSeconds INTEGER NOT NULL
On 21 Jan 2017, at 4:32pm, James K. Lowden wrote:
> Cecil Westerhof wrote:
>
>> I would think that this would work:
>> UPDATE desktops
>> SET indexNo = indexNo + 1
>>
>> But it does not, it gives:
>> Error: UNIQUE constraint failed: desktops.indexNo
>
> It should work. It does work in othe
On 2017/01/21 12:54 PM, Cecil Westerhof wrote:
I have the following (work in progress) table:
CREATE TABLE desktops(
nameTEXTNOT NULL PRIMARY KEY,
indexNo INTEGER NOT NULL UNIQUE,
value TEXTNOT NULL UNIQUE,
waitSeconds INTEGER NOT NULL
);
I want
On Sat, 21 Jan 2017 11:54:57 +0100
Cecil Westerhof wrote:
> I would think that this would work:
> UPDATE desktops
> SET indexNo = indexNo + 1
>
> But it does not, it gives:
> Error: UNIQUE constraint failed: desktops.indexNo
It should work. It does work in other DBMSs, but it doesn't in
SQLit
Here's one possibility (simplified table for example):
create table desktops(
indexno integer not null unique,
nametextnot null primary key
);
insert into desktops values
(1,'CompA'),
(2,'CompB'),
-- we want to insert new record here bumping all above by one
(3,'CompD'),
(4,'CompE');
Quick note: the mailing list doesn't accept attachments.
-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of SASSOULAS Pierre 250112
Sent: Friday, January 20, 2017 11:25 AM
To: sqlite-users@mailinglists.sqlite.org
Subject: [sqlite] Seg
On 1/21/17, Cecil Westerhof wrote:
> I have the following (work in progress) table:
> CREATE TABLE desktops(
> nameTEXTNOT NULL PRIMARY KEY,
> indexNo INTEGER NOT NULL UNIQUE,
> value TEXTNOT NULL UNIQUE,
> waitSeconds INTEGER NOT NULL
> );
>
> I want to
On 1/20/17, Tim Uy wrote:
> Hi, I currently start a :memory: database and then attach a physical
> database and then set wal mode by using
>
> PRAGMA mydb.journal_mode=WAL
>
> 1. Is this safe? (I noticed default is 'delete')
DELETE is the default because it works in a wider variety of
situations,
It seems this is intended behavior. From sqlite.org/lang_conflict.html
under REPLACE:
> If a NOT NULL constraint violation occurs, the REPLACE conflict
resolution replaces
> the NULL value with the default value for that column, or if the column
has no default
> value, then the ABORT algorithm is
Hello everyone,
I've been experimenting with an interesting form of statement that tries to
implement an "upsert" operation and came across some unusual behavior. For
context, my table has a notion of a "logical key" aside from the primary
key, and this is what determines whether to update or inse
Hi, I currently start a :memory: database and then attach a physical
database and then set wal mode by using
PRAGMA mydb.journal_mode=WAL
1. Is this safe? (I noticed default is 'delete')
2. Can I do it automatically with the ATTACH? So I don't have to wait 150
ms for the WAL PRAGMA statement?
___
Hi,
I've encountered a segfault in a python-django project when inserting seemingly
random innocent looking data into an sqlite3 databse. It happen while testing a
custom command in Django unit-test.
Version :
python --version
Python 2.7.12
sqlite3 --version
3.11.0 2016-02-15 17:29:24 3d862f20
On Sat, 2017-01-21 at 11:54 +0100, Cecil Westerhof wrote:
> I have the following (work in progress) table:
> CREATE TABLE desktops(
> nameTEXTNOT NULL PRIMARY KEY,
> indexNo INTEGER NOT NULL UNIQUE,
> value TEXTNOT NULL UNIQUE,
> waitSeconds INTEGER NOT NU
I have the following (work in progress) table:
CREATE TABLE desktops(
nameTEXTNOT NULL PRIMARY KEY,
indexNo INTEGER NOT NULL UNIQUE,
value TEXTNOT NULL UNIQUE,
waitSeconds INTEGER NOT NULL
);
I want to insert a record in front of the others, so indexNo
18 matches
Mail list logo
