6.0.0-alpha14
7/3/25

[#9760] QUERY FAILED: Duplicate entry 'xxx' for key 'rampage_users_user_name' INSERT INTO `rampage_users` (user_name) VALUES ('xxx')
Summary QUERY FAILED: Duplicate entry 'xxx' for key 'rampage_users_user_name' INSERT INTO `rampage_users` (user_name) VALUES ('xxx')
Queue Kronolith
Queue Version 3.0-RC2
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester Klaus.Steinberger (at) physik (dot) uni-muenchen (dot) de
Created 03/31/2011 (5208 days ago)
Due
Updated 11/03/2014 (3895 days ago)
Assigned 04/01/2011 (5207 days ago)
Resolved 04/06/2011 (5202 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
11/03/2014 12:26:44 PM arjen+horde (at) de-korte (dot) org Comment #9 Reply to this comment
This is caused as the usernames are checked literally instead of 
case-insensitive.
Which is correct as many backends are case sensitive. If yours is not 
and you want to correct this, Horde provides a preauthenticate hook 
(see horde/config/hooks.php.dist) to change the case to whatever you 
prefer. An example for precisely this use case is provided.
Ive just had this problem where in the past someone had logged in as 
'DAVID' and also as 'david', once I updated the column 
event_creator_id in the kronolith_events table so it was all the 
same the upgrade worked fine after. I also had same problem with 
turba.
This has been discussed many times before already.
11/03/2014 11:40:35 AM ricardo (at) wenn (dot) com Comment #8 Reply to this comment
This is caused as the usernames are checked literally instead of 
case-insensitive.
Ive just had this problem where in the past someone had logged in as 
'DAVID' and also as 'david', once I updated the column 
event_creator_id in the kronolith_events table so it was all the same 
the upgrade worked fine after. I also had same problem with turba.
04/06/2011 09:10:00 AM Jan Schneider State ⇒ Resolved
 
04/06/2011 05:23:06 AM Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de Comment #7 Reply to this comment
I am unable to reproduce this, both with a fresh set of tag tables, 
and with existing tag info present.
The final solved the problem for me, so this could be closed.
04/01/2011 01:34:00 PM Michael Rubinsky Comment #6
State ⇒ Feedback
Reply to this comment
I am unable to reproduce this, both with a fresh set of tag tables, 
and with existing tag info present.

Can you:

in content/lib/Users/Manager.php after line 72 add:
Horde::debug($sql);
Horde::debug($this->_db->selectAll($sql));

and then after line 79 add:
Horde::debug($userName);

the results will be placed in a file named 'horde_debug.txt' in your 
temporary directory. Then please post the results here.
03/31/2011 03:25:42 PM Jan Schneider Assigned to Michael Rubinsky
State ⇒ Assigned
 
03/31/2011 03:03:35 PM Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de Comment #5 Reply to this comment
Depends on where you installed PEAR. Could be in /usr/bin/.
Run:
pear list-files horde/horde
Ahh it's /usr/bin/horde-db-migrate

Ok here is the output:

[root@dmz-sv-webmail ~]# horde-db-migrate --debug kronolith
[  INFO  ] Migrating DB up.
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0026s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0003s)
         SELECT version FROM kronolith_schema_info
[  INFO  ] Current kronolith schema version: 17
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0004s)
         SELECT type_id, type_name FROM `rampage_types` WHERE type_name IN
           ('calendar','event')
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0018s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0006s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0013s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0003s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0013s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0003s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0013s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0014s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0001s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0012s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0001s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0016s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0003s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0003s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0020s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0003s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0019s)
         SHOW TABLES
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT version FROM kronolith_schema_info
Migrating to KronolithUpgradeCategoriesToTags (18)
== 18 KronolithUpgradeCategoriesToTags: migrating 
=============================
== 18 KronolithUpgradeCategoriesToTags: Migrating event categories to 
tags. ===
-- select(SELECT event_uid, event_category, event_creator_id, 
calendar_id FROM kronolith_events)
    -> 0.0005s
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0418s)
         SELECT event_uid, event_category, event_creator_id, calendar_id FROM
           kronolith_events
-- getOption(charset)
    -> 0.0000s
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0004s)
         SELECT object_id, object_name FROM `rampage_objects` WHERE object_name
           IN ('20060423181823.1qybe4lucog0@www.physik.uni-muenchen.de') AND
           type_id = 2
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0004s)
         SELECT user_id, user_name FROM `rampage_users` WHERE user_name IN
           ('xxx')
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0005s)
         SELECT * FROM kronolith_sharesng WHERE share_name = 'xxx'
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT * FROM kronolith_sharesng_users WHERE share_id = '65'
-- getOption(charset)
    -> 0.0000s
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0005s)
         SELECT object_id, object_name FROM `rampage_objects` WHERE object_name
           IN ('20060423181823.1qybe4lucog0@www.physik.uni-muenchen.de') AND
           type_id = 2
2011-03-31T17:01:10+02:00 DEBUG: SQL  (0.0002s)
         SELECT user_id, user_name FROM `rampage_users` WHERE user_name IN
           ('xxx')
2011-03-31T17:01:10+02:00 DEBUG: SQL QUERY FAILED: Duplicate entry 
'xxx' for key 'rampage_users_user_name'
         INSERT INTO `rampage_users` (user_name) VALUES ('xxx')
2011-03-31T17:01:10+02:00 DEBUG: SQL
         INSERT INTO `rampage_users` (user_name) VALUES ('xxx')
QUERY FAILED: Duplicate entry 'xxx' for key 'rampage_users_user_name'

INSERT INTO `rampage_users` (user_name) VALUES ('Kaspar.Graf')
[root@dmz-sv-webmail ~]#
03/31/2011 02:52:40 PM Jan Schneider Comment #4 Reply to this comment
Depends on where you installed PEAR. Could be in /usr/bin/.
Run:
pear list-files horde/horde
03/31/2011 02:33:18 PM Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de Comment #3 Reply to this comment
Please run the migration from the console and post the output here:

./horde/bin/db_migrate --debug kronolith
Where is this script?  I didn't find ist. Some more pear module to install?
03/31/2011 01:47:05 PM Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Please run the migration from the console and post the output here:

./horde/bin/db_migrate --debug kronolith
03/31/2011 01:39:12 PM Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de Comment #1
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ Kronolith
Summary ⇒ QUERY FAILED: Duplicate entry 'xxx' for key 'rampage_users_user_name' INSERT INTO `rampage_users` (user_name) VALUES ('xxx')
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
I tried to use our database from our production Horde 3 server and 
Update the DB Schema to horde 4.

Any tables worked except the schema for kronolith, where I got this error:

QUERY FAILED: Duplicate entry 'xxx' for key 'rampage_users_user_name' 
INSERT INTO `rampage_users` (user_name) VALUES ('xxx')

(I replaced the real username by xxx).


Saved Queries