zurück zur Übersichtsseite

Mit Dynamics 365 v9 on-premise an der "bleeding edge"

Als Microsoft-Partner und Dynamics 365-Implementer gehört es zu unserem Job, immer die neusten Technologien und Produktversionen zu testen und natürlich auch für uns selbst zu nutzen. Nur so entsteht fundiertes Wissen, mit dem wir unsere Kunden exzellent unterstützen können.
So geht es uns auch mit Dynamics 365 in der v9, die wir – wie bislang alle CRM / Dynamics 365-Versionen – on-premise bereitstellen, da einige komplexe und hoch-angepasste Funktionalitäten schlicht noch nicht in der Cloud-Version abbildbar sind.
Nun müsste man von einem solchen (teuren und bereits etablierte) Produkt erwarten können, dass es zumindest bei einer völlig neuen und Handbuch-konformen Installation nicht auf der Startseite schon einen Fehler wirft. Doch weit gefehlt. Wird die v9 auf einem Server in deutscher Sprache neu installiert, gibt es im

- - Lesezeit: 3 min
Kategorie: Microsoft Dynamics

Der Fehler

Der "Social Feed" liefert als Fehler – in hübschem rot – "Fehler. Warten Sie einen Moment, und versichen Sie es dann erneut. […]". Eine weitere Ursachenforschung bringt über die Entwickerkonsole im Browser einen Stack-Trace hervor. Darin heißt es schon etwas spezifischer: Crm Exception: Message: The requested record matches a specified If-None-Match version., ErrorCode: -2147088246 So richtig aussagekräftig ist das aber auch nicht. Weiter ging es über CRM Traces, aber auch hier fand sich nichts Brauchbares. Somit kamen wir zum letzten Mittel, um dem Fehler auf die Schliche zu kommen. Einem Tracing der vom CRM ausgeführten Statements auf dem SQL-Server. Und hier kam etwas Licht ins Dunkel. Für den Inhalt des Social Feed wird eine stored procedure aufgerufen. diese liegt in der jeweiligen Mandanten-Datenbank und heißt p_RetrievePosts. Ein Beispielaufruf sah wie folgt aus: exec p_RetrievePosts @entityId='FEA8D5B7-052B-E511-9402-00155D0D6E93',@entityTypeCode=8,@includeFollowing=1,@currentUserId='FEA8D5B7-052B-E511-9402-00155D0D6E93',@type=-1,@source=-1,@pageNumber=1,@pageSize=20,@commentsPerPost=2,@startDate=default,@endDate=default Diesen Aufruf haben wir nun über das Management Studio manuell ausgelöst – und einen Fehler erhalten. Dieser war zum ersten Mal qualifiziert genug, um auf die Ursache schließen zu können. Problematisch ist der Datumsparameter endDate beim Aufruf mit dem Wert "default". Dieser ist in der stored procedure mit dem Wert "31-Dec-9999" vorbelegt. Ein deutscher SQL-Server kann das nicht verarbeiten. Er erwartet "Dez" – oder einen Zahlenwert, wie 12. Hier wurde scheinbar bei der Lokalisierung geschlampt.  

Lösungsansatz

Was nun tun? Natürlich mit Microsoft sprechen. Aber einen schnellen Fix verspricht dieses Vorgehen zunächst nicht. Daher mussten wir uns selbst helfen. Am Ende haben wir beschlossen, die stored procedure dahingehend zu verändern, dass wir den Standardwert von @endDate auf "31-Dez-9999" verändert haben. Damit ist der Fehler im Social Feed sofort verschwunden. Darüber hinaus funktioniert es auch korrekt und wie erwartet. Natürlich ist dieses Vorgehen seitens Microsoft nicht unterstützt. Und die Chance, dass das nächste Update die stored procedure zurücksetzt hoch. Dennoch ein Lösungsweg, wenn er bedacht beschritten wird.



Letzte Beiträge

„Unsere Produktion läuft nach einem Hacker-Angriff wieder normal“

| Lesezeit 4 min

mehr lesen

Internet – Ist das echt noch immer Neuland für uns Deutsche?

| Lesezeit 9 min

mehr lesen