[Gelöst] System.OutOfMemoryException beim Customizing Exprot

Hallo zusammen,

mein CRM kostet mich manchmal wirklich den letzten Nerv

Gestern war noch alles gut, ich konnte das Customizing komplett exportieren. Geändert habe ich danach gar nicht mal viel wenn ich mich recht entsinne war es tatsächlich nur eine Spalte die ich in einer Zugeordneten Ansicht einer Benutzerdefinierten Entität hinzugefügt habe. Diese Entität habe ich dann auch veröffentlicht und alles war so wie gewünscht.

Heute wollte ich dann wieder das ganze Customizing exportieren, ich hab mir irgendwie angewöhnt selbst vor den kleinsten Änderungen das gesamte Customizing zu exportieren, und da geht es nicht mehr.

Es erscheint folgende Meldung:

<?xml version="1.0" ?>
- <error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<displaytitle />
<displaytext />
<description>Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.</description>
<file>Not available</file>
<line>Not available</line>
<details>Eine Ausnahme vom Typ "System.Web.HttpUnhandledException" wurde ausgelöst.</details>
<requesturl>http://crm/CRM/_grid/cmds/dlg_exportcustomizations.aspx</requesturl>
<pathAndQuery>/CRM/_grid/cmds/dlg_exportcustomizations.aspx</pathAndQuery>
<source>XML</source>
<stacktrace />
</error>

Ich kann auch die Tracelogmeldungen einstellen, wenn das nötig ist. Mir haben die nicht wirklich weitergeholfen leider. (Edit: Ich hab die Tracemeldugnen mal als Datei angehängt. Wegen der Lesbarkeit dachte ich ist Anhang besser als den Text hier reinzuschreiben. Ich hoffe ich habe den Forumsknigge da richtig verstanden. )

Da ich ein ähnliches Problem schonmal hatte bin ich hingegangen und habe erst die erste Hälfte des Customizings exportiert, dann die zweite Hälfte, um rauszubekommen wo das Problem liegt. Ging aber bei beiden Hälften ohne Schwierigkeiten. Ich hab dann noch ein bischen mehr rumprobiert und festgestellt das ich nur die Entitäten und Sicherheitsrollen plus ISV und Sitemap ohne Workflows exportieren kann. Nur die Workflows exportieren geht auch. Wenn ich dann von Adressen an 223 Einträge nach unten markiere und exportiere geht es auch. Bei 224 streikt das CRM dann und bringt wieder obigen Fehler. Wenn ich aber von Adressen an bis vor den erste Workflow gehe und dann erst mit den letzten Workflows Anfange kann ich bis zu 255 Einträge exportieren.

Für mich sieht das jetzt irgendwie so aus als hätten die Entitäten an sich kein Problem, sondern als wäre es die Summe aller Entitäten die irgendwie zu groß für den Export ist oder so. Kann das sein? Aber ich frage mich wie weil gestern ging es ja noch und seit dem sind ja keine Entitäten dazugekommen. Also ich bin irgendwie mehr als Ratlos. Und wäre über Hilfe sehr dankbar.

Viele Grüße
Nicole

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von Nicole Schmitz am 16. November 2010 16:47, insgesamt 1-mal geändert.

Hallo Nicole,

eine solche Fehlermeldung wird im MSDN behandelt:

http://msdn.microsoft.com/de-de/library/9w766t6y(VS.80).aspx

Die Aussagen des Artikels dort decken sich mit den Beobachtungen, die du beschrieben hast. Bedenke dabei, dass nicht jedes CRM-Objekt im exportierten Zustand genau gleich groß ist und somit durch die "richtige" Auswahl an Objekten durchaus auch das eine oder andere Objekt mehr in einen Teil-Export reinpasst.

Eine gegenfrage mit evtl. Vorschlag:
Enthält dein Customizing viel Javascript? Falls ja, kann der (meines Wissens unsupportete) Weg über das Auslagern des JavaScripts in eine externe .js-Datei einiges an Speicher eingespart werden, da der Javascript-Code beim Export ja mit in die entstandene XML reingeschrieben wird. Sofern dies mehrere Entitäten betrifft, kann sich das durchaus summieren

Hallo,

erstmal danke für die schnelle Antwort.

Zu deiner Frage, ja unser Customizing enthält schon recht viel JavaScript allein um bei bestimmten OnChance Events von Lookupfeldern Daten aus der verknüpften Entität zu ziehen und noch einiges mehr. Viele der Scripte wiederholen sich natürlich in unterschiedlichen Entitäten. Jedoch möchte ich nur sehr ungerne einen unsupporteten Weg einschlagen. Bisher habe ich mich meines Wissens immer im supporteten Bereich bewegt und wollte das natürlich wenn möglich auch weiter so halten.

Was ich noch nicht ganz verstehe ist wie diese eine kleine Änderung von gestern bis heute dieses Problem ausgelöst hat ich habe ja nur eine Spalte in einer Ansicht hinzugefügt. Zumal in meinem Testszenario auch nicht wirklich weniger JavaScript enthalten ist und da geht noch alles. Wobei da sind zwar alle Workflow eingespielt aber fast keine veröffentlicht vielleicht deswegen?

Ich werde mal meine Entitäten durchgehen und sehen wo ich vielleicht JavaScripts einsparen kann. Aber wenn jemand noch eine Idee für eine Supportete Lösung hat wäre ich sehr dankbar.

Grüße
Nicole

Jedoch möchte ich nur sehr ungerne einen unsupporteten Weg einschlagen. Bisher habe ich mich meines Wissens immer im supporteten Bereich bewegt und wollte das natürlich wenn möglich auch weiter so halten.

Wir händeln das wie folgt: Wir nutzen ein Verzeichnis im wwwroot/ISV/Scripts in das alles reinkommt. Dies ist ein Verzeichnis, bei dem Microsoft garantiert, es bei einem Rollup nicht anzufassen. Genau diesen Weg wurde mir übrigens auch von dem Trainingsleiter meiner Entwicklerschulung empfohlen. Hat bei uns vor allem den Hintergrund, dass man bei Bedarf das Script nur einer und nicht an hundert Stellen korrigieren muss

Ob der Weg wirklich offiziell unsupportet ist ist, bin ich mir nicht 100% sicher, vielleicht kann ja jemand anders diese Frage hier beantworten.

Was ich noch nicht ganz verstehe ist wie diese eine kleine Änderung von gestern bis heute dieses Problem ausgelöst hat ich habe ja nur eine Spalte in einer Ansicht hinzugefügt.

Eine Spalte wird im exportierten XML durch einen entsprechenden Unterknoten des XMLs abgebildet. Das ist sicherlichnicht viel Text - kann aber zufällig genau das Fass zum Überlaufen gebracht haben. Ich muss jedoch gestehen, dass ist Spekulation.

Zumal in meinem Testszenario auch nicht wirklich weniger JavaScript enthalten ist und da geht noch alles. Wobei da sind zwar alle Workflow eingespielt aber fast keine veröffentlicht vielleicht deswegen?

Im XML wird der Unterschied "veröffentlicht/nicht veröffentlicht meines Wissens nach lediglich durch einen true/false - Wert gekennzeichnet. Das macht also nichts aus.

Hallo,

also das auslagern von JavaScript in eine externe Datei ist ganz offiziell ein unsupporter Weg. Das an sich ist noch nicht wirklich tragisch. Was mich dabei viel mehr stört ist die Tatsache, das durch das auslagern der JavaScripte in externe Dateien das Laden dieser Scripte schlicht und ergreifend länger dauert, was bei vielen javaScripten durchaus zu problemen führen kann.

Jetzt aber zur eigentliche Frage des Artikels, warum es Probleme mit dem Export aller Anpassungen gibt. Dabei handelt es sich schlicht und ergreifend um ein Timingproblem. Das CRM benötigt zu lange, die entsprechende Datei zu schreiben.

Es gibt aktuell eine Lösung und einen Workarround für das Problem. Die Lösung ist, das aktuelle RU13 einzuspielen und die RegKeys zum Thema OleDb einzurichten. Mit diesen kann das Timing Verhalten des CRM verändert werden. Es gibt einen sehr schönen Artikel von Carsten, der die möglichen Regkeys beschreibt und auch immer gleich einen Verweis auf den entsprechenden KB Artikel enthält. Ihr findet den Artikel hier.

Der Workarround ist, einfach den Export in zwei Dateien vorzunehmen, um die Datenmenge zu verringern.

Hallo,

danke für den Link zu Carstens Artikel, den kannte ich noch nicht und der wird mir sicher noch an mancher Stelle weiterhelfen.

Eine Frage habe ich dazu aber noch. Wir setzen bei uns noch das RU 8 ein und ich wäre ganz glücklich wenn ich das einspielen des neuen RUs noch etwas aufschieben könnte. Wenn ich den KB Artikel der in Carstens Artikel bei OLEDBTimeout und ExtendedTimeout verlinkt ist richtig lese, da wird ja CRM 3.0 erwähnt, dann müssten diese beiden Registryeinträge doch auch schon früher vorhanden gewesen sein und dem entsprechend müssten die auch bei uns mit RU 8 schon eingestellt werden können. Sehe ich das richtig?

Ansonsten werde ich bis auf weiteres den beschriebenen Workaround nutzen und das Customizing in zwei Paketen exportieren. Einmal die Entitäten und einmal die Sicherheitsrollen und Workflows. Dann treten auch keine Probleme bei Beziehungen zwischen zwei Benutzerdefinierten Entitäten auf. Das hatte ich nämlich schonmal - war auch unschön. Ich hatte immer befürchtet das das CRM bei "Alle Anpassungen exportieren" noch mehr exportiert als man so im einzelnen sieht und selbst exportieren kann. Aber wenn dem nicht so ist ist das mit den zwei Paketen zum Export ja auch ok.

Über die Information ob die beiden Regeinträge auch schon mit RU 8 bekannt waren wäre ich noch sehr dankbar. Ansonsten wurde mir hier schon super weitergeholfen. Vielen Dank euch beiden.

Grüße
Nicole

Hallo Nicole,

Eine Frage habe ich dazu aber noch. Wir setzen bei uns noch das RU 8 ein und ich wäre ganz glücklich wenn ich das einspielen des neuen RUs noch etwas aufschieben könnte. Wenn ich den KB Artikel der in Carstens Artikel bei OLEDBTimeout und ExtendedTimeout verlinkt ist richtig lese, da wird ja CRM 3.0 erwähnt, dann müssten diese beiden Registryeinträge doch auch schon früher vorhanden gewesen sein und dem entsprechend müssten die auch bei uns mit RU 8 schon eingestellt werden können. Sehe ich das richtig?

Der Artikel ist bereits 2008 erschienen, so das er im RU 8 enthalten sein wird.
Selbst wenn nicht, stellt das kein Problem da, da das CRM System unbekannte regKeys einfach ignoriert und es nicht zu einem Fehler kommen kann.