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

On 4/15/2017 1:33 PM, the famous troll Thomas 'Pointed Head' Lahn wrote:
> 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 said: "...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 is no problem, then the problem must be solved. You can't
>> backpedal out of it.
>
> You should listen to your mindless babbling some time.
>

ROFLMAO. I'm just quoting YOU.

>>> Data integrity cannot be compromised by import because NOTHING RELEVANT
>>> is referring to the table YET.
>>
>> Once again you show you understand NOTHING about data integrity in a
>> relational database.
>
> Pot calling the kettle black.
>

ROFLMAO! Another ad hominem attack.

>> Importing data into two tables which are related is relevant.
>
> 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.)
>

Then how do you import data from one RDB to another? Oh, I guess according to you, you can't.

> If it is BROKEN ALREADY, you CANNOT break it AGAIN.
>

It wasn't broken before you got involved.

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

It wasn't broken before you got involved.

>>>> The data being inserted into the new database is NOT "empty".
>>> I have NOT said that the *data* is empty. Learn to read.
>>
>> Once again: "I have to emphasize *again* that the target table *in this
>>>>> case* was *empty*.".
>>
>> There is no such thing as "empty data".
>
> You should listen to your incoherent, inconsistent babbling some time.
>

ROFLMAO! I'm quoting YOU.

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

I never claimed such.

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

Nope. That's not what you said, no matter how much you try to backpedal.

>>>>> 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.
>>
>> Bullshit. There very well could have been a foreign key involved.
>
> But then the DATA INTEGRITY WOULD BE COMPROMISED ALREADY.
>

Nope. The data were correct before you got involved.

>> But your renumbering of the primary key of the table has now broken that
>> relationship.
>
> 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.
>

Nope. Once again you show a complete lack of understanding of relational databases. But that's pretty normal for you. No wonder you're such a well-known troll in so many newsgroups. You insist on displaying your ignorance time and time again.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex_at_attglobal.net
==================