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

[Quoted] On 4/15/2017 9:19 AM, Thomas 'PointedEars' Lahn wrote:
> Peter H. Coffin wrote:
>
>> On Tue, 11 Apr 2017 08:36:17 -0400, Jerry Stuckle wrote:
>>> In either case the database will be seriously borked with foreign keys
>>> pointing at the wrong data.
>>
>> And that is, im my humble opinion, a point of such importance that it
>> may as well be the ONLY point.
>
> 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.
>

[Quoted] And that's where you are wrong. Just being aware that foreign keys are invalid does NOT solve the problem.

> 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.
>

[Quoted] So what? The data being inserted into the new database is NOT "empty". [Quoted] And it is this data which will be corrupted with your bad advice.

>> Data integrity is paramount.
>
> So much for that.
>

Yes, you've already proven you have no idea how do ensure data integrity.

>> Build the table without a primary key, FIND THE DUPLICATES, resolve them
>> (by hand, if necessary) so that the data is intact and correct, THEN add
>> the primary key back.
>
> 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.
>
>

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

The result is a seriously borked database. But you have already shown you do not understand relational databases and how to maintain database integrity.

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