locked
stsadm -o restore generates error RRS feed

  • Question

  • I am trying to restore a 2007 SharePoint Site Collection to a test farm. Everytime I run a stsadm -o restore, the command prompt gives me an "Operation is not valid due to the current state of the object."

    If I look in event viewer it says:"Unknown SQL Exception 547 occured. Additional error information from SQL Server is included below. The INSERT statement conflicted with the FOREIGN KEY constraint "FK_SiteMap_Database". The conflict occurred in database "SharePoint_Config", table "dbo.Objects", column 'Id'.
    The statement has been terminated." 


    What is it that I need to do to resolve this?
    Monday, August 12, 2013 9:11 PM

Answers

  • Hi Pasha90,

    There are several possibilities here.

    2 ways we can think...

    We should begin by thinking about what from the site in question (site/subsites/solutions/webparts/Lists/timer job/templates/featuredefinition etc) could have landed up on destination farm at some point in past. If we could manually track that (based on knowledge/information about that particular environment and its recent history)  , finding what we need to do next would be much easier.

    Otherwise 1 easy way is to run SQL profiler (capturing all events for SharePoint_Config DB and Objects Table) and from the query that you see failing/being attempted we can check the value of fields such as ID, Name and the complete XML (if available) for the Properties field. These will confirm what is the object causing issue and we can go from there accordingly...

    If its not the case of something already existing on destination from past from source, it could then mean we have an issue related to an orphan object/or schema corruption on the source or destination. Getting rid of orphans or such corruption is not easy. You could try detaching the DB for the source site but be ware if we do have an issue with orphans indeed it could fail to attach back causing source to go down. Having said that the profiler trick will at least tell where we are failing.

    If this does not answer your question, it might mean answering it requires a more in-depth level of support which is not feasible through Forums. Please visit the below link to see the various paid support options that are available to better meet your needs:http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. If you are a MSDN / TechNet subscriber, you can also contact our support by using your free support incidents.
    However, other members of the community may still have encountered the issue you're seeing, and may have a solution to offer.

    Regards,

    Sukesh.

    • Marked as answer by pasha90 Monday, August 19, 2013 6:01 PM
    Thursday, August 15, 2013 9:59 AM

All replies

  • Hi,

    I believe the ID's you are trying to insert with

    stsadm -o restore command

    are already there in the Configuration databases. These can be the IDs for solutions or webparts.

    Hope it helps!

    Monday, August 12, 2013 9:31 PM
  • how do I identify and remove those IDs?

    Monday, August 12, 2013 9:32 PM
  • Hi,
    For this issue, I’m trying to involve someone familiar with this topic to further look at it.
    Thanks,
    Qiao
    Forum Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Qiao Wei
    TechNet Community Support

    Wednesday, August 14, 2013 12:12 AM
    Moderator
  • Hi Pasha90,

    There are several possibilities here.

    2 ways we can think...

    We should begin by thinking about what from the site in question (site/subsites/solutions/webparts/Lists/timer job/templates/featuredefinition etc) could have landed up on destination farm at some point in past. If we could manually track that (based on knowledge/information about that particular environment and its recent history)  , finding what we need to do next would be much easier.

    Otherwise 1 easy way is to run SQL profiler (capturing all events for SharePoint_Config DB and Objects Table) and from the query that you see failing/being attempted we can check the value of fields such as ID, Name and the complete XML (if available) for the Properties field. These will confirm what is the object causing issue and we can go from there accordingly...

    If its not the case of something already existing on destination from past from source, it could then mean we have an issue related to an orphan object/or schema corruption on the source or destination. Getting rid of orphans or such corruption is not easy. You could try detaching the DB for the source site but be ware if we do have an issue with orphans indeed it could fail to attach back causing source to go down. Having said that the profiler trick will at least tell where we are failing.

    If this does not answer your question, it might mean answering it requires a more in-depth level of support which is not feasible through Forums. Please visit the below link to see the various paid support options that are available to better meet your needs:http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. If you are a MSDN / TechNet subscriber, you can also contact our support by using your free support incidents.
    However, other members of the community may still have encountered the issue you're seeing, and may have a solution to offer.

    Regards,

    Sukesh.

    • Marked as answer by pasha90 Monday, August 19, 2013 6:01 PM
    Thursday, August 15, 2013 9:59 AM
  • I ended up contacting Technical Support. They discovered the Web Front End was not attached to the farm properly. We detached and reattached and it worked. Thanks for your help.
    Monday, August 19, 2013 6:02 PM