Some of you during a restor (STSADM restore that is) might have come across this erorr:
Exception from HRESULT: 0x80040E2F
This HRESULT simply means, "Violation of PRIMARY KEY constraint ", which generally means one thing, you have entries in the database for this site previously, possibly orphaned, that is preventing the restore to continue.
Sometimes a simple -overwrite after the restore command would work, but sometimes the problem isn't that there was orphaned data to begin with, but rather "New" data related to the site added outside of the restore, that then causes the restore to fail.
The reason in this case, may be due to the fact that while the restore is progressing, the site isn't locked and therefore users accessing the site is causing the duplicate entries.
2 easy ways to fix this:
- Lock the site from Central Admin
- Switch off the site from IIS and remember to start it once the restore is complete.
This should fix your problem. If you are still having this issue, let me know and ill see if i can help.
5 comments:
Have you ever come across this error while editing a List Item? That's when I get this error.
http://johannes-prinz.blogspot.com/2009/01/hresult-0x80040e2f-why-me.html
is it all items in that list or just that specific item? was the list created by code or through the gui?
Fadi
"Similar" Situation:
Have restored PROD data back into QA to "refresh" the QA farm with current data. This includes "MySites" db.
Upon attempting to visit a "MySite", you first recieve this error (subject line of this blog post), then if you hit refresh, the provision process then recreates the profile, and your restored data is visible.
No more occurences for that particular user.
But, each and every user will see this.
Ergo, our "restore" method will result in several hundred HelpDesk calls... not a palatable situation.
I see many people saying the "fix" is to restore it this way and that... but that is not necessarily a fix, but an avoidance technique for it to occur.
Is there a "fix"... I.e, the situation is in play, and I can submit:
stsadm + some specific combo of switches that will "fix" the situation
It seems clear that what is at odds is that you are directing the web server to fetch a page that doesn't exist, but has data behind it...
Is there not a way farm way to "re-apply"
I see possibilities here:
http://community.officesharepointpro.com/forums/post/21420.aspx
But i dont see anyone who has verified that this will work?
I had the same thing. If you create a new web app with a different name (and different url) it will work then. Not sure why it doesn't clean itself up properly.
Same problem here, does someone have any solution already?
Post a Comment