Serverseitige Abhängigkeiten fehlen [MissingWebPart]

C.Kaiser Als Antwort am 1 Feb. 2011 11:31

Hilft dir das weiter?

http://blogs.architectingconnectedsystems.com/blogs/cjg/archive/2009/12/09/Missing-Server-Side-Dependencies-_2D00_-8d6034c4_2D00_a416_2D00_e535_2D00_281a_2D00_6b714894e1aa.aspx

Edit: Keine Änderungen direkt an der DB vornehmen, sondern "nur" die Query ausführen und die aufgelisteten Seiten mal anklicken ;-)

Christian Müller Als Antwort am 1 Feb. 2011 11:32

oder das?

http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/4f6dfbaa-7634-4797-aa1d-d2970308e39f

Ingo Wozny Als Antwort am 1 Feb. 2011 13:25

@Christinan: Irgendwie leider nicht, ich kann mich zwar mit einem Sharepoint Farmadministrator über das Management Studio auf die Sharepoint Instanz einloggen, aber Abfragen kann/darf ich nicht machen, wie hier auch beschrieben...

http://weblogs.mysharepoint.de/blogs/fabianm/archive/2008/09/06/name-der-inhaltsdatenbank-der-sharepoint-zentraladministration-amp-228-ndern.aspx

@Christian Müller: Leider auch nicht, weil wir nur einen Foundation Server im Einsatz haben, dort gibt es den Menüpunkt "Suche" gar nicht in der Zentraladministration. :-(

@Alle: Kann man nicht den Webpart anhand der ID ausfindig machen und dann löschen oder evtl. neu installieren?

Peter Oswald Als Antwort am 6 Nov. 2012 08:10

Wir haben mit dem gleichen Fehler zu kämpfen, und zwar nachdem wir Sites auf andere Content Databases verschoben haben.

Die o. g. "Workarounds" helfen da aber nicht (und warum ein Aufrufen einer Seite oder das Einsetzen von iisreset in Verbindung mit der Search Service Application diesen fehlerhaften Datenbankeintrag löschen soll, ist mir ohnehin ein Rätsel). Hat jemand noch Tipps oder Hinweise für die Fehlerbehandlung?

Peter Oswald Als Antwort am 27 Nov. 2012 12:10

So, ich habe mich in letzter Zeit öfter mit diesem Thema auseinandersetzen müssen. Hier meine Resultate:

Folgende Szenarien führen offenbar immer früher oder später zu so einem MissingWebpart-Fehler:

• Zurückziehen einer Farmlösung ohne vorheriges Deaktivieren der Features in den WebsiteCollections
• Farmlösung wurde zurückgezogen und mit einer Version überspielt, die andere Feature-Namen bzw. Setup-Pfade für das Feature enthält.

Es ist offenbar nicht möglich, diese Fehler dann durch gezieltes (Un-)Deployment zu korrigieren. Sind die Leichen übrig, dann werden sie bis ans Ende aller Tage in der Content-DB mitgeschleppt, und, was noch viel schlimmer ist, sie blähen als Error-Traces die Logs und damit die Datenbank über einen größeren Zeitraum unnötig auf. Schon wegen den Error-Logs ist es notwendig, die MissingWebpart-Errors zu entfernen. Doch was tun, wenn diese nicht über den herkömmlichen Weg zu vernichten sind? Uns half folgende Vorgehensweise:

• Suche per SQL-Skript auf der Inhaltsdatenbank nach einem markanten Stichwort aus der Fehlermeldung. Dazu wird ein Skript gestartet, dass alle Tabellen der Datenbank durchsucht. Eine Referenz für so ein Skript liefert
  http://blogs.thesitedoctor.co.uk/tim/2010/02/19/Search+Every+Table+And+Field+In+A+SQL+Server+Database+Updated.aspx
• Die Resultate aus dem SQL-Skript sichten und die richtigen löschen. Fehlerhafte MissingWeb-Part-Einträge liefern vor allem die Tabellen AllDocs und FeatureTracking. Die meisten fehlerhaften Verweise tauchen beim Installationspfad auf. Hier besonders auf die Spalten "SetupPath" und "Folder" achten. Hier bleiben oft alte Verweise als Leichen zurück. Diese können gelöscht werden.

Und nun noch der obligatorische Warnhinweis: klar, das ist eher eine Operation am offenen Herzen und man muss wissen und vor allen Dingen vorher kontrollieren, was man löscht. In unserem Fall hat das aber geholfen und der Server läuft wieder fehlerfrei.

Krass ist übrigens auch, wenn derartige Fehler entstanden sind, ohne dass man es gerade mitbekommen hat, und man beginnt dann Websites auf eigene / neue Content-DBs zu verschieben. Dann hat man u. U. gleiche mehrere MissingWebpart-Fehler auf einmal, weil die Verweise auf die Leichen auch mitkopiert werden...