Hi.
'0' (i.e. Zero) has a special meaning for AUTO_INCREMENT, namely the
same as NULL, which will choose a automatically a new value for the
column. (Btw, are you sure, that you get the error for the row which
was '0' and not for the one which was '72' - the latter sounds more
probably to me).
Basically, MySQL shoulnd't have allowed you to set the value '0' via
UPDATE at first. This could be considered a bug.
I know no work-around for you. Restoring the '0' value by hand isn't a
solution either, because it could happen that this will be forbidden
by MySQL sooner or later.
Bye,
Benjamin.
On Mon, Feb 05, 2001 at 05:42:27PM -0800, [EMAIL PROTECTED] wrote:
> I have been using MySQL for ecommerce work for quite some time. One
> problem that just recently arose was a duplicate key error during db
> restoration. The culprit lies in a table which has an
> auto_incremented, not null defined integer field called "id". There
> is an entry which was adjusted, by me, to have an "id" of 0 (instead
> of 1). When mysql attempts to restore this table, after a backup, it
> complains that the entry (which previously had the "id" of 0) now has
> an "id" of 72, and is invalid as there already is an entry with an id
> of 72.
>
> Basically it seems that restore cannot allow for a zero value, if the
> field is an auto_incremented, not null primary key. This seems like
> a serious problem, since many ecommerce table designs use a zero
> value in such a table to represent a catalog base.
>
> Is there any solution in mysql?
[...]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
