• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Plesk 11.5 Horde reports "A fatal error has occurred" SQLSTATE[23000]

SacAutos

Regular Pleskian
This particular issue is with my CentOS 6.4 server running Plesk 11.5.30/MU13. This was a freshly built server with a clean install of everything. Shortly after we started moving domains there I noticed that I would receive, on occasion, error messages like this in Horde:

"A fatal error has occurred

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'fdca4edc9d6d3cf250506f34beac38b2' for key 'PRIMARY'

Details have been logged for the administrator."

If I refreshed the page, usually the error would go away. Now I'm hearing that other users of Horde are also getting this same error message. How do I diagnose and fix?
 
Integrity constraint violation: 1062 Duplicate entry 'fdca4edc9d6d3cf250506f34beac38b2' for key 'PRIMARY'

Fixed in MU#14
 
Igor, I'm sad to report that I saw my server was updated to MU14 last night. Yet I received one of those error messages again this morning.
 
Good morning. In going through my email with Horde, I received that error message again:

"A fatal error has occurred

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'fdca4edc9d6d3cf250506f34beac38b2' for key 'PRIMARY'

Details have been logged for the administrator."

It's always exactly the same entry key: fdca4edc9d6d3cf250506f34beac38b2. What database table is that? Is that something I can clean up myself? Any ideas at all why this is happening?
 
It is difficult to say what is wrong in database without access to database. Therefore I suggest you contact Support Team.
Also you can dump psa, apsc, horde databases and try to find in dumps mentions of this fdca4edc9d6d3cf250506f34beac38b2 This way you will find a place where this duplicate entry is stored. Try to remove it after that.
 
Unfortunately I would have to pay to open a support ticket. I'm still holding out hope that I can solve this on my own.

Meanwhile, one of my customers sent me an email regarding the error message she was getting on the server with her email. The screen snapshot shows exactly the same error message! What's up with that? How can two separate domains (though on the same server) have exactly the same database key??
 
Thanks for reminding me Igor. Today was a loss due to a customer's email account getting hacked. Spent all day identifying the account and deleting the spam. I'll try that tomorrow.
 
Igor, I dumped the Horde database today and found this entry:

INSERT INTO `horde_cache` (`cache_id`, `cache_timestamp`, `cache_expiration`, `cache_data`) VALUES
('fdca4edc9d6d3cf250506f34beac38b2', 1379373902, 1379375702, 0x30);

(This wasn't the only item in the cache - there were perhaps twenty more.) Is it safe to delete this and the others? Suggestions??
 
I see today that the server has applied MU#15. However, the SQLSTATE errors are now even worse than before. in reading my email this morning I must have seen that error ten times. Previously I might get it once or twice during a session. Whatever the update addressed didn't apply to this issue.
 
same happened to us with plesk 11.5.30 MU20 (upgrade from 10.x), running in centos, customer complained this morning about it. 2nd attempt works, difficult to reproduce, probably session related.
 
Back
Top