1062 Duplicate entry '0' for key 1 after export/import of database

[DrByte]

Please see below for things I have found that look a bit odd while checking each tables “Auto_Increment” is on and that the Next Autoindex number is correct when checking against the primary field under the browse option for that table :
· featured table shows value 11 for Next Autoindex but the browse option is greyed out
· products_attributes table shows value 1,104 for Next Autoindex but browse button greyed out
· specials table shows value 51 for the Next Autoindex but browse button greyed out
· banners table shows value 56 for the Next Autoindex but browse button greyed out

If the browse button is greyed out, that means there's no data in the table to be browsed

· email_archive table - not found in mysql

If you're not archiving any emails then that won't matter. But it begs the question of "how" did it disappear? If it's missing during a database-upgrade, you may run into errors that will cause upgrade challenges since it will have to abort mid-stream. Thus I suggest that you recreate it perhaps from a backup.

· configuration table shows the following warning UNIQUE and INDEX keys should not both be set for column `configuration_key`

That's normal, and can be ignored.

1062 Duplicate entry '0' for key 1
in:
[insert into banners_history (banners_id, banners_shown, banners_history_date) values ('55', 1, now())]

"key 1" is probably the primary key on the table, which would be the banners_history_id field.
Since the "insert" statement doesn't mention that field (and this is normal and desired), it is expecting the auto-increment attribute of that field to automatically select the correct next number. So, if you're getting that error on that table, it means the banners_history_id is not set to autoincrement.

Admin:
1062 Duplicate entry '0' for key 1
in:
[insert into admin_activity_log (access_date, admin_id, page_accessed, page_parameters, ip_address) values (now(), '1', 'store_manager.php', '', '198.54.202.30')]

Same issue as mentioned above for banners_history table.


If it was working flawlessly until a certain date, then unless it's something you or your staff have done to the site, your first line of support for these odd database issues should be your hosting company -- so they can investigate what may be wrong on the server to break the autoincrement funcitonality.