Keith, this type of detailed response is why i rate this list so highly
above most others. These are the threads i learn the most from :-D.
+1
Sorry for top-posting - writing on a phone.
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On May 7, 2012 4:44 PM, "Ke
> In an SQL statement that inserts, deletes, or updates many rows,
> SQLite as well as MySQL InnoDB checks UNIQUE and FOREIGN KEY
> constraints row-by-row.
> According to the SQL standard, the default behavior should be deferred
> checking.
> http://stackoverflow.com/questions/7703196/sqlite-incre
On May 7, 2012, at 4:10 PM, Marc L. Allen wrote:
> I don't see the issue with that. Unless you want it to fail anyhow?
Fair enough. I just didn't fully realize the dramatic implications of 'or
replace' in conjunction with update.
> You have a unique key. You execute an update that sets all
e the 'right thing' as being different?
> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Petite Abeille
> Sent: Monday, May 07, 2012 10:05 AM
> To: General Discussion of SQLite Database
> Subject: R
On May 7, 2012, at 3:44 PM, Pavel Ivanov wrote:
> It's a well documented feature: "or replace" means "if you see
> constraint violations while updating please delete all violating rows
> and then proceed with update"
Yep, I'm familiar with the ON CONFLICT clause. Or I thought I was as I haven't
On May 7, 2012, at 3:44 PM, Richard Hipp wrote:
> Call it whichever you want. SQLite has *always* worked this way, for
> reasons that go very deeply into the design. And applications exists which
> depends on the current behavior. So it probably isn't going to change.
Primum non nocere. Rathe
>> Whether a row is deleted depends on whether the row being updated clashes
>> with a current row when adding one.
>
> Yep. Bug or feature? Looks like a bug to me, or a least a very unwelcome
> misfeature :/
It's a well documented feature: "or replace" means "if you see
constraint violations w
On Mon, May 7, 2012 at 9:35 AM, Petite Abeille wrote:
>
> On May 7, 2012, at 3:24 PM, Marc L. Allen wrote:
>
> > Apparently, the update is done a row at a time.
>
> Yep, therefore the OP inquiry about DEFERRABLE INITIALLY DEFERRED for
> unique constraints.
>
> > Whether a row is deleted depends o
On May 7, 2012, at 3:24 PM, Marc L. Allen wrote:
> Apparently, the update is done a row at a time.
Yep, therefore the OP inquiry about DEFERRABLE INITIALLY DEFERRED for unique
constraints.
> Whether a row is deleted depends on whether the row being updated clashes
> with a current row when a
General Discussion of SQLite Database
> Subject: Re: [sqlite] Bug: Increment unique integer field
>
>
> On May 7, 2012, at 2:48 PM, Igor Tandetnik wrote:
>
> > begin;
> > update numbers set num = -num;
> > update numbers set num = -num + 1;
> > end;
&
On May 7, 2012, at 2:48 PM, Igor Tandetnik wrote:
> begin;
> update numbers set num = -num;
> update numbers set num = -num + 1;
> end;
Right… now… out of curiosity… what happen when you do the following:
update or replace numbers set num=num+1;
Note the 'or replace'. Did that 'update or repl
Petite Abeille wrote:
> create table numbers(num int unique );
> insert into numbers( num ) values( 1 );
> insert into numbers( num ) values( 2 );
> insert into numbers( num ) values( 3 );
>
> sqlite> update numbers set num=num+1;
> Error: column num is not unique
begin;
update numbers set num
On May 7, 2012, at 11:57 AM, John Yani wrote:
> In an SQL statement that inserts, deletes, or updates many rows,
> SQLite as well as MySQL InnoDB checks UNIQUE and FOREIGN KEY
> constraints row-by-row.
> According to the SQL standard, the default behavior should be deferred
> checking.
Right, S
In an SQL statement that inserts, deletes, or updates many rows,
SQLite as well as MySQL InnoDB checks UNIQUE and FOREIGN KEY
constraints row-by-row.
According to the SQL standard, the default behavior should be deferred checking.
http://stackoverflow.com/questions/7703196/sqlite-increment-unique-i
14 matches
Mail list logo
