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

From: Thomas 'PointedEars' Lahn <PointedEars_at_web.de>
Date: Tue, 11 Apr 2017 13:54:04 +0200
Message-ID: <1778879.oMNUckLgyt_at_PointedEars.de>

J.O. Aho wrote:

[Quoted] > On 04/10/17 21:43, Thomas 'PointedEars' Lahn wrote:

>> J.O. Aho wrote:

>>> as the data dump would otherwise have the primary key.
>>> […]

>> No, I have tested it. Jerry is correct about the possibility.
>>
>> In theory, if the target table has
>>
>> | mysql> SHOW CREATE TABLE `t1`\G
>> | […] CREATE TABLE `t1` (
>> | `id` int(…) NOT NULL DEFAULT '0',
>> | `foo` VARCHAR(50),
>> | […]
>> | PRIMARY KEY (`id`)
>> | ) […]
>>
>> and the offending statement(s) is/are of the form
>>
>> INSERT INTO `t1` (`foo`) VALUES ('zero'),('one'),('two');
>
> No, if you make a default dump (not option given) […]

*If*. That it is a default dump is *your* *assumption*. It does not need to be correct.

>>> Just think of the idea where you wouldn't have the primary key and you
>>> insert data into another database, which may been used and tables just
>>> truncated, so then the auto_increment wouldn't necessarily start from 1
>>> and you would suddenly have an inconsistent database and a lot of errors
>>> when key constraints wouldn't work.

JFTR: As I showed, you can set the AUTO_INCREMENT value of a table before data import.

>> And yet it is a distinct possibility. For a dump of a single table
>> instead of the whole database, it might even be intentional.
>
> The issue still there and wouldn't happen with a default dump.

That is precisely my point. (Apparently I have not made myself clear enough.) The evidence suggests that this file is not the result of a default dump.

> As the OP not given any more information, so all we say are just > speculations.

And there is no logic in excluding other possibilities, and dismiss suggestions pertaining to those.

.
.
.
.
.
.
.

-- 
PointedEars

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

Received on Tue Apr 11 2017 - 13:54:04 CEST