We have been actively developing Drupal 4.65 (going to 4.66 but need to fix this first)
We are getting this on all new domains installed.
When we try to login
user error: Duplicate entry '0' for key 1
query: INSERT INTO watchdog (uid, type, message, severity, link, location, hostname, timestamp) VALUES (1, 'user', 'Session opened for admin.', 0, '', '/user/login?destination=node', '69.180.217.227', 1143885170) in /home/[username]/public_html/includes/database.mysql.inc on line 67.
After this error screen we are in fact logged in but...
When we try to logout.
user error: Duplicate entry '0' for key 1
query: INSERT INTO watchdog (uid, type, message, severity, link, location, hostname, timestamp) VALUES (1, 'user', 'Session closed for admin.', 0, '', '/logout', '69.180.217.227', 1143881936) in /home/[username]/public_html/includes/database.mysql.inc on line 67.
We can't add users and can't only login as admin but even that is hard and strange.
Its not the stuff found in this link.
We've tried truncating watchdog and sessions and increasing the session id to 64 varchar as per the above link.
A developer made some changes in database.mysql.inc with sequences about a month ago and any new domains we add from that code are like this.
I'm not sure what he did and can't remember why it was needed but I don't think he knows how to fix. Either way we can't seem to get an answer on this and was hoping for some help.
I've pasted in the changes he made. The first entry is the patch applied to the database.mysql.inc file and I assume this is the problem. I may be wrong I don't know. Note that the entry after the '+' does not in fact wrap. I say this because this format for a diff is odd to me but comes straight form Subversion so who am I to question? It is one line obviously.
database.mysql.inc
Here is the patch that was applied
@@ -151,7 +151,7 @@
*/
function db_next_id($name) {
$name = db_prefix_tables($name);
- db_query("INSERT INTO {sequences} (name) VALUES ('%s') ON DUPLICATE KEY UPDATE id = id + 1;", $name);
+ db_query("INSERT INTO {sequences} (name) VALUES ('%s') ON DUPLICATE KEY UPDATE id = id + 1 + (LAST_INSERT_ID(id+1)*0);", $name);
return mysql_insert_id();
}
This is how it is now and I would assume what is causing the problem.
function db_next_id($name) {
$name = db_prefix_tables($name);
db_query("INSERT INTO {sequences} (name) VALUES ('%s') ON DUPLICATE KEY UPDATE id = id + 1 + (LAST_INSERT_ID(id+1)*0);", $name);
return mysql_insert_id();
}
Comments
Forget this. In this case we had several different problem
I was able to solve by stepping back on version on our database. Then I tried to figure out why that would work. we are Running Mysql 5.x and this was a dump to 4.x with the campatibility mode set for 4.0 as it should be. The problem was in the auto increment. This version of Phpmyadmin either did not add it properly or we did not choose it. BEWARE. Heh.
Compatability mode with comments?
Was this compatability mode implemented with comments? These are stripped by phpmyadmin.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
A simple fix for us..
We were getting this error (one very similar) after moving to a new server with exporting and importing from phpMyAdmin.
For some reason the auto_increment attribute was not set on the 'wid' field in the 'watchdog' table. I had 'Add AUTO_INCREMENT value' selected on the export, but for whatever reason I had to manually go in and turn on auto_increment on the field and that fixed it.
Also changed default value
Thanks for your valuable advice.
I had the same problems after a migration to different server.
I went into phpadmin and set the auto_increment for the WID-field.
At first I received an error about the default value. I then also had to remove the default value, which was set for 0. It should be an empty field.
Hans
http://www.hansdekker.com
Oh how I love this forum
I exported the database from phpmyadmin2.7.0 (local) to 2.6.2 (remote) and thought I'd never fix this. But it runs smoothly as ever :)
thanks!
Patrick
http://www.kajak-media.nl
Got this too! It was from
Got this too! It was from dupming from PAM with MSQL40 compatibility. It doesn't add the AUTO_INCREMENT after the field definition.
I'd say, export without any compatibility then go search and replace for the ENGINE/DEFAULT_CHARSET and change to TYPE and remove the charset.
Nice!
Rob
------------------
Some of my Drupal sites:
Quotes | MySpace Layouts
Watch out with exporting from phpAdmin
It worked for me. When exporting an existing Drupal db to an other installation, remember to clear the cache table as well.
solved
i solved it by simply
exporting as mysql40
and changing the auto increment for the table accesslog and watch dog
BUT
what if i made changes on my local mashines
and i want to keep both changes data online and offline
what should i use for export "update" "insert" repalce" ?
and does anyone know the difference between
complete data inserts, extended inserts etc ?
be careful
Be careful, many tables do contain "auto increment" so u will get many errors else where
any new data about exporting from mysql to 4 ?
A safer way...
I too got a similar error after transferring my site. Here's what I did:
That's it. All the relevant tables, including watchdog and accesslog, should now have their auto_increment set and (apart from cache and accesslog) be populated with your old data.