Re: Duplicate entry '0' for key 'PRIMARY'
From: Thomas 'PointedEars' Lahn <PointedEars_at_web.de>
Date: Sat, 15 Apr 2017 16:05:25 +0200
Message-ID: <1903229.irdbgypaU6_at_PointedEars.de>
>
> And that's where you are wrong. Just being aware that foreign keys are
> invalid does NOT solve the problem.
>
> So what?
>
> It *MAY* detect inconsistencies. For instance, if there is a foreign
> key pointing to a non-existent primary key, it will detect that.
> However, if the foreign key is pointing to the *WRONG ROW* because *THE
> PRIMARY KEY HAS CHANGED*, it will not detect the error.
Date: Sat, 15 Apr 2017 16:05:25 +0200
Message-ID: <1903229.irdbgypaU6_at_PointedEars.de>
[Quoted] Jerry Stuckle wrote:
> On 4/15/2017 9:19 AM, Thomas 'PointedEars' Lahn wrote:
>> AISB, as long as one is *aware* that any foreign keys referring to that >> table are then invalid, too, then there is no problem. If there are >> (non- NULL) foreign keys referring that table, then one should work with >> a *copy* of either the target table or the target database.
>
> And that's where you are wrong. Just being aware that foreign keys are
> invalid does NOT solve the problem.
[Quoted] I did NOT say that it solves the problem. Learn to read.
>> But apparently I have to emphasize *again* that the target table *in this >> case* was *empty*. Any non-NULL foreign keys referring to it would have >> been *invalid in the first place*, and NULL foreign keys would not >> matter.
>
> So what?
[Quoted] Data integrity cannot be compromised by import because NOTHING RELEVANT is referring to the table YET.
> The data being inserted into the new database is NOT "empty".
[Quoted] I have NOT said that the *data* is empty. Learn to read.
> And it is this data which will be corrupted with your bad advice.
Bullshit.
>> ACK, and the mere *attempt* to add the primary key (or any other key) >> (back) with key checks *enabled* will *result* in *detecting* those >> inconsistencies already. AISB.
>
> It *MAY* detect inconsistencies. For instance, if there is a foreign
> key pointing to a non-existent primary key, it will detect that.
> However, if the foreign key is pointing to the *WRONG ROW* because *THE
> PRIMARY KEY HAS CHANGED*, it will not detect the error.
[Quoted] [Quoted] But IN THIS CASE there should not be a foreign key referring to that table in the first place. If it were, data integrity would already be compromised.
-- PointedEars Twitter: _at_PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.Received on Sat Apr 15 2017 - 16:05:25 CEST