Benutzer mit den meisten Antworten
[gelöst] Fehler bei Berichten mit langer Ausführungszeit

Frage
-
Hallo,
ich habe ein Problem beim Ausführen von Berichten, das ich im folgenden kurz schildern möchte.
Umgebung (CRM-Server):
MS Windows Server 2003 R2 Standard Edition SP2,
MS SQL Server 2005 Standard Edition SP3 (alle Komponenten),
MS Dynamics CRM 4.0 Professional Edition + Update Rollup 12
Es wurden einige Berichte auf folgende Weise erstellt:- Zunächst wurden auf dem CRM-Server Views erstellt, die die für die Berichte benötigten Daten zusammensammeln. Diese Views benutzen ihrerseits die Filtered...-Views des CRM-Systems. Da die in den Views enthaltenen Abfragen recht komplex sind, ist die Ausführungszeit auch relativ lang (> halbe Stunde).
- Auf einem separaten Rechner (Entwicklungsrechner) wurden mittels Visual Studio 2005 SP1 Berichte erstellt. Dabei wurde der CRM-Server als DataSource bzw. die besagten Views als DataSets eingebunden. Beim Testen unter VS (Vorschau) funktionierten die Berichte trotz der langen Ausführungszeit einwandfrei.
- Schließlich wurden die Berichte ins CRM importiert, über die CRM-Web-Oberfläche, mittels Berichte/Neu, Berichtstyp=Vorhandene Datei, Dateispeicherort=<von VS erstellte RDL-Datei>, etc.
Startet man einen so erstellten Bericht jetzt direkt von CRM aus, so bricht er nach ein paar Minuten ab mit der Meldung "Fehler -- Es ist ein Fehler aufgetreten. -- Wiederholen Sie die Aktion. [...] ". Im Event-Log auf dem CRM-Server findet sich folgender Eintrag:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ereignistyp: Warnung
Ereignisquelle: ASP.NET 2.0.50727.0
Ereigniskategorie: Webereignis
Ereigniskennung: 1309
Datum: 29.11.2010
Zeit: 13:24:54
Benutzer: Nicht zutreffend
Computer: TU-CRM02
Beschreibung:
Ereigniscode: 3005
Ereignismeldung: Es ist eine unbehandelte Ausnahme aufgetreten.
Ereigniszeit: 29.11.2010 13:24:53
Ereigniszeit (UTC): 29.11.2010 12:24:53
Ereignis-ID: 38f86b39a8a144bf97f36ee092b4a367
Ereignissequenz: 39
Vorkommen: 1
Ereignisdetailcode: 0
Anwendungsinformationen:
Anwendungsdomäne: /LM/W3SVC/1/ROOT-1-129355064365957762
Vertrauensebene: Full
Virtueller Anwendungspfad: /
Anwendungspfad: c:\inetpub\wwwroot\
Computername: TU-CRM02
Prozessinformationen:
Prozess-ID: 4164
Prozessname: w3wp.exe
Kontoname: NT-AUTORITÄT\NETZWERKDIENST
Ausnahmeinformationen:
Ausnahmetyp: SoapException
Ausnahmemeldung: System.Web.Services.Protocols.SoapException: Die Ausführung 'gqcvvfnmj5wc1bjbudbrdr45' wurde nicht gefunden. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: Die Ausführung 'gqcvvfnmj5wc1bjbudbrdr45' wurde nicht gefunden.
--- Ende der internen Ausnahmestapelüberwachung ---
bei Microsoft.ReportingServices.WebServer.ReportExecution2005Impl.GetExecutionInfo(ExecutionInfo& executionInfo)
bei Microsoft.ReportingServices.WebServer.ReportExecutionService.GetExecutionInfo(ExecutionInfo& executionInfo)
Anforderungsinformationen:
[den Müll schenke ich mir jetzt mal]
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ungeachtet der kryptischen Fehlermeldung scheint es sich im Grunde um ein Timeout-Problem zu handeln. Um dies zu überprüfen habe ich mal testweise die komplexe Abfrage in einem der Views durch eine triviale Abfrage ersetzt, die praktisch sofort ein Ergebnis liefert (mittels ALTER VIEW). Danach funktionierte der davon abhängige Bericht -- technisch -- korrekt (inhaltlich wurden natürlich nicht mehr die korrekten Daten angezeigt).
Nun ist die Frage, ob es irgendwo eine "Stellschraube" gibt, mit der man CRM dazu bringen kann, auch Berichte mit langer Ausführungszeit korrekt auszuführen. Da die Ausführungszeit aus Anwendersicht nachrangig ist, wäre das Problem damit für mich gelöst.
Ich habe übrigens auch noch mit Einträgen in der Registrierung unter HKLM\Software\Microsoft\MSCRM\ gespielt, die mit irgendwelchen Rollups eingeführt bzw. irgendwo im Netz beschrieben wurden:- NormalTimeout auf 36000000 (=10 Std.) raufgesetzt
- ExtendedTimeout auf 36000000 (=10 Std.) raufgesetzt
-- leider ohne Erfolg.
Jetzt weiß ich nicht mehr weiter, hat jemand anders eine Idee?- Bearbeitet Gernot Meyer Donnerstag, 2. Dezember 2010 16:32 Problem gelöst
Antworten
-
Hallo Gernot,
es gibt noch weitere RegKeys, die du versuchen kannst. Es gibt dazu einen sehr schönen beitrag von Carsen Groth, den du hier finden kannst:
http://carstengroth.wordpress.com/2010/11/08/microsoft-dynamics-crm-4-0-wichtige-registry-settings/
Viele Grüße
Michael Sulz
MVP für Microsoft Dynamics CRM
Blog
Website- Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:25
-
Hallo,
ich habe durch Zufall doch noch eine Lösung gefunden:
Es gibt in der Datei C:\Inetpub\wwwroot\web.config, das ist die web.config in dem Basisverzeichnis für die MSCRM-Website, also wo die CRM-relevanten Dateien für den IIS abgelegt sind, ein Attribut executionTimeout:
<configuration> <system.web> <httpRuntime executionTimeout="300" maxRequestLength="8192"/> </system.web> </configuration>
(Dieser Codeblock entspricht dem Inhalt der Datei web.config in stark verkürtzer Form, um zu zeigen, wo genau in der XML-Struktur sich das besagte Attribut befindet.)
Setzt man den Wert von 300 auf z. B. 3000 hoch, also von 300sek=5min auf 50min, dann werden die Berichte korrekt erstellt.
Seltsamerweise werden die kryptischen EventLog-Einträge ("Es ist eine unbehandelte Ausnahme aufgetreten.") immer noch erzeugt, jedesmal, wenn ein Bericht erstellt wird. Also besteht, anders als ursprünglich vermutet, zwischen diesen Einträgen und dem Fehler, der zunächst bei der Berichtserstellung auftrat, gar kein ursächlicher Zusammenhang.
- Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:22
Alle Antworten
-
Hallo Gernot,
es gibt noch weitere RegKeys, die du versuchen kannst. Es gibt dazu einen sehr schönen beitrag von Carsen Groth, den du hier finden kannst:
http://carstengroth.wordpress.com/2010/11/08/microsoft-dynamics-crm-4-0-wichtige-registry-settings/
Viele Grüße
Michael Sulz
MVP für Microsoft Dynamics CRM
Blog
Website- Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:25
-
Hallo Michael,
vielen Dank für die Antwort!
Allerdings kommt von den RegKeys m. E. nur noch OLEDBTimeout in Betracht, um einen Timeout festzulegen. Das habe ich jetzt auch getestet, d. h. ich habe den Wert auf 86400 (=24 Std.) hochgesetzt, allerdings ohne Erfolg.
Die anderen RegKeys sind 0/1-Flags, mit denen man irgendwelche Rollup-Verbesserungen aus- und einschalten kann. Die hatte ich beim Einspielen des Rollups ohnehin bereits entsprechend der Dokumentation in der Knowledgebase gesetzt, d. h. ich hatte vorsichtshalber alle Features eingeschaltet, damit mir sozusagen nichts entgeht.
Viele Grüße -
Hallo Gernot,
weitere Stellschrauben kenne ich nicht. Was hälst du von der Idee, die Reports zeitgesteuert auszuführen und dann für eine bestimmte Zeit schreibzuschützen und diesen bereits ermittelten Report anzuzeigen. Gerade bei Reports mit langen Laufzeiten macht dies aus meiner Sicht Sinn.
Ob das allerdings das Timeout-Problem löst, müsstest du erst einmal ausprobieren.
Viele Grüße
Michael Sulz
MVP für Microsoft Dynamics CRM
Blog
Website -
Hallo,
ich habe durch Zufall doch noch eine Lösung gefunden:
Es gibt in der Datei C:\Inetpub\wwwroot\web.config, das ist die web.config in dem Basisverzeichnis für die MSCRM-Website, also wo die CRM-relevanten Dateien für den IIS abgelegt sind, ein Attribut executionTimeout:
<configuration> <system.web> <httpRuntime executionTimeout="300" maxRequestLength="8192"/> </system.web> </configuration>
(Dieser Codeblock entspricht dem Inhalt der Datei web.config in stark verkürtzer Form, um zu zeigen, wo genau in der XML-Struktur sich das besagte Attribut befindet.)
Setzt man den Wert von 300 auf z. B. 3000 hoch, also von 300sek=5min auf 50min, dann werden die Berichte korrekt erstellt.
Seltsamerweise werden die kryptischen EventLog-Einträge ("Es ist eine unbehandelte Ausnahme aufgetreten.") immer noch erzeugt, jedesmal, wenn ein Bericht erstellt wird. Also besteht, anders als ursprünglich vermutet, zwischen diesen Einträgen und dem Fehler, der zunächst bei der Berichtserstellung auftrat, gar kein ursächlicher Zusammenhang.
- Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:22