Re: Duplicate entry '0' for key 'PRIMARY'

Jerry Stuckle wrote:

> On 4/15/2017 10:05 AM, Thomas 'PointedEars' Lahn wrote:

>> I did NOT say that it solves the problem.  Learn to read.

You should listen to your mindless babbling some time.

[Quoted] >> Data integrity cannot be compromised by import because NOTHING RELEVANT
>> is referring to the table YET.

Pot calling the kettle black.

> Importing data into two tables which are related is relevant.

[Quoted] But they SHOULD NOT be related in this case in any practical sense of the word. There SHOULD NOT be any records in the first table referring to the second one because the second one is EMPTY. (Foreign key constraints can make sure of that in operation, but not with MyISAM; InnoDb is recommended.)

[Quoted] If it is BROKEN ALREADY, you CANNOT break it AGAIN.

[Quoted] And AISB, if it is BROKEN, then it needs to be FIXED FIRST. BEFORE attempting to import ANYTHING else.  

[Quoted] >>> The data being inserted into the new database is NOT "empty".
>> I have NOT said that the *data* is empty.  Learn to read.

>>>> case* was *empty*.".

You should listen to your incoherent, inconsistent babbling some time.

[Quoted] If there is no such thing as ?empty data?, why have you claimed that there could be?

[Quoted] And I did NOT say that there was empty DATA. A said that the target TABLE is empty here. Got it now?

[Quoted] >>>> 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.
>> 
>> 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.

But then the DATA INTEGRITY WOULD BE COMPROMISED ALREADY.

> But your renumbering of the primary key of the table has now broken that
> relationship.

[Quoted] [Quoted] Either there ARE records in any table that refer to the EMPTY target table by foreign key, then the relationship is BROKEN ALREADY. Or there are NO such records, then NOTHING will be broken by adding data to an EMPTY TABLE.

-- 
PointedEars

Twitter: _at_PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.