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

[Quoted] [Quoted] On 4/15/2017 10:05 AM, Thomas 'PointedEars' Lahn wrote:
> 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] 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.

>>> 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] Once again you show you understand NOTHING about data integrity in a [Quoted] [Quoted] relational database. Importing data into two tables which are related is relevant.

>> The data being inserted into the new database is NOT "empty".

[Quoted] Once again: "I have to emphasize *again* that the target table *in this >>> case* was *empty*.".

[Quoted] There is no such thing as "empty data". It either exists or it does not.

>> And it is this data which will be corrupted with your bad advice.

Yup, that's what you are full of. For sure.

>>> 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] Bullshit. There very well could have been a foreign key involved. But [Quoted] your renumbering of the primary key of the table has now broken that relationship.

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