[GELÖST]Einspielen von Update Rollup 11schlägt auf Datenbank

[Dirk Schlarmann]

Hallo,

habe folgendes Problem:
Auf einer Testumgebung haben wir jetzt Update Rollup 11 eingespielt.
Die Installation an sich lief wunderbar durch. Wenn man nun in den Bereitstellungsmanager schaut sieht man aber, dass die Organisationen noch auf der alten Version von Update Rollup 8 sind 5.0.9690.2243 anstatt auf 5.0.9690.2835.

In diesem Fall wird in Bereitstellungsmanager der Button "Update" angeboten, sobald man diese auf eine der Organisationen anwendet erscheint eine Fehlermeldung: "Vorhandene SQL Server-Verbindung mit Microsoft Dynamics CRM-Datenbanken müssen geschlossen werden, bevor die Installation fortgesetzt werden kann."

Kein Problem. Nächster Versuch:
Organisation Deaktivieren und Löschen und anschließend über "Organisationen importieren" wieder hinzufügen, was auch funktioniert, jedoch kann das Update auf UR 11 nicht auf die Datenbank ausgeführt werden.

In der Log-Datei erscheint folgende Fehlermeldung:
"Ausnahmefehler beim Anwenden der Datenbankupdates auf die Organisation mit dem Namen = xxxx, ID=xxxxxxx-xxxx-xxxx-xxxxxxxxxxxx:
System.Data.SqlClient.SqlException (0x80131904): Bei der Konvertierung eines varchar-Datentyps in einem datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs."

Weiß hier jemand einen Lösungsansatz?

[Michael Sulz]

Hallo Dirk,

welche UR Version hat die Datenbank, die du updaten möchtest?

[Dirk Schlarmann]

Die Datenbank ist auf Stand UR 10v2.
Die Voraussetzung für Update Rollup 11 ist Update Rollup 6, oder?

[Michael Sulz]

ja, die Voraussetzung ist UR 6

[Michael Sulz]

Hallo,
wann hast du das RU vom Server geholt? Seit dem 23.10.gibt es ein v2 für das Serverupdate.

[Dirk Schlarmann]

Hallo,

ja, das ist mir auch aufgefallen. Hatte anfangs die alte Version von vor dem 23.10. verwendet.
Gestern habe ich die neue Version auch ausprobiert und leider mit dem gleichen Fehler.

[sci]

Hallo,

bei uns tritt das selbe Phänomen auf.
Beim Anlegen einer neuen Organisation, bleibt selbst die neu angelegte Datenbank auf UR6.

[FrRi]

Guten Tag,

Wir hatten eine Neuinstallation mit UR6 und dann, nach grundlegendem Testen der Installation, UR11v2 nachinstalliert. Dabei hatten wir den gleichen Effekt, wie, Dirk Schlarmann beschrieben hat. Unangenehm ist, dass es scheint, dass die Installation fehlerfrei durchläuft, erst beim Kontrollieren der Logs bzw. der installierten Versionen fällt dies auf.

„Update abgeschlossen
13:58:20| Info| Update Rollup 11 für Microsoft Dynamics CRM Server (KB2739504-V2) wurde erfolgreich abgeschlossen. Das Datenbankupdate schlug jedoch für einige Organisationen fehl.“

Bisher haben wir leider auch noch keinen Lösungsansatz

Gruß Frank Richter

[Michael Sulz]

Hallo Frank,

dann hilft eigentlich nur das Tracing einzuschalten und dann ein Update der Organisation durchzuführen.

[RalfEmons]

Guten Tag,

wir haben die 2 Dienste für die asynchrone Verarbeitung beendet, Danach lässt sich die Organisation updaten! Wir bekommen dann einen Fehler:

System.Data.SqlClient.SqlException (0x80131904): Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.
Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.
Die Anweisung wurde beendet.

Hat dazu jemand eine Idee?

VG,

RE

[christian.mueller]

Hallo zusammen,

konnte das Problem erfolgreich lösen: auch bei mir schlug das Update auf Rollup 11 per Installer fehl mit der Meldung, dass einige Organisationsdatenbanken nicht aktualisiert werden konnten. Ein Update der Org-DBs kann nachträglich noch einmal über den Deployment-Manager gestartet werden. Hierfür müssen alle DB-Connections geschlossen sein! D.h. auch die CRM Async-Services und andere Dienste, die evtl. auf die Org-DBs zugreifen, müssen beendet werden (wie bereits weiter oben beschrieben).

Per SQL Profiler konnte ich herausfinden, dass kurz vor dem fehlerhaften Abbruch das folgende SQL Statement an die DB gesendet wird:

>>> START >>>

!!! ACHTUNG: FEHLERHAFTES SQL STATEMENT !!!

-- Morocco Standard Time:
-- Morocco will switch to daylight saving time from 2012 onwards. The Moroccan government has changed the 2012 DST start date to occur on the last
-- Sunday of April and end date to occur on the last Sunday of September. During the time of Ramadan, DST will be interrupted and from July 20 to
-- August 19, 2012, time will be turned back to standard time.

IF EXISTS (SELECT * from TimeZoneDefinitionBase WHERE TimeZoneDefinitionId = 'A57C8407-74AF-47f0-B1D8-86575C134EC0')
BEGIN
IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = '275515A8-F651-4C94-98EE-C04C63537D1B')
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, '2012/1/1', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '275515A8-F651-4C94-98EE-C04C63537D1B', 0,
0, 0, 9, 5, 0, 3, 0, 0,
-60, 0, 4, 5, 0, 2, 0, 0)
END

IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = '546D7620-34E9-4565-AD10-72BA30486C37')
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, '2012/07/20', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '546D7620-34E9-4565-AD10-72BA30486C37', 0,
0, 0, 0, 0, 0, 0, 0, 0,
-60, 0, 0, 0, 0, 0, 0, 0)
END

IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = '86F4ACFB-3E69-474E-AAAF-238419C38801')
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, '2012/08/19', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '86F4ACFB-3E69-474E-AAAF-238419C38801', 0,
0, 0, 9, 5, 0, 3, 0, 0,
-60, 0, 4, 5, 0, 2, 0, 0)
END
END

<<< END <<<

Die beiden letzten insert-Statements wurden bei mir versucht auszuführen, da die beiden TimeZoneRule-Datensätze nicht vorhanden waren. Hierbei fällt aber auf, dass die Notation der beiden "Datums-Werte" ('2012/07/20' bzw. '2012/08/19') nicht korrekt ist (YYYY/MM/DD). Diese müssten - laut ENU-Lokalosierung - '2012/20/07' bzw. '2012/19/08' lauten (YYYY/DD/MM). Das korrekte Statement lautet also folgendermaßen:

>>> START >>>

!!! KORRIGIERTES SQL STATEMENT !!!

-- Morocco Standard Time:
-- Morocco will switch to daylight saving time from 2012 onwards. The Moroccan government has changed the 2012 DST start date to occur on the last
-- Sunday of April and end date to occur on the last Sunday of September. During the time of Ramadan, DST will be interrupted and from July 20 to
-- August 19, 2012, time will be turned back to standard time.

IF EXISTS (SELECT * from TimeZoneDefinitionBase WHERE TimeZoneDefinitionId = 'A57C8407-74AF-47f0-B1D8-86575C134EC0')
BEGIN
IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = '275515A8-F651-4C94-98EE-C04C63537D1B')
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, '2012/1/1', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '275515A8-F651-4C94-98EE-C04C63537D1B', 0,
0, 0, 9, 5, 0, 3, 0, 0,
-60, 0, 4, 5, 0, 2, 0, 0)
END

IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = '546D7620-34E9-4565-AD10-72BA30486C37')
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, '2012/20/07', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '546D7620-34E9-4565-AD10-72BA30486C37', 0,
0, 0, 0, 0, 0, 0, 0, 0,
-60, 0, 0, 0, 0, 0, 0, 0)
END

IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = '86F4ACFB-3E69-474E-AAAF-238419C38801')
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, '2012/19/08', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '86F4ACFB-3E69-474E-AAAF-238419C38801', 0,
0, 0, 9, 5, 0, 3, 0, 0,
-60, 0, 4, 5, 0, 2, 0, 0)
END
END

<<< END <<<

Führt man das korrekte Statement gegen ALLE Org-DB Datenbanken per SQL Management Studio aus, sind die beiden TimeZoneRule-Records vorhanden und man kann den Update-Prozess für die Organisation(en) über den Deployment-Manager noch einmal ausführen! Dabei sollte der Updateprozess erfolgreich durchlaufen (bei mir war es so!).

Beste Grüße
Christian

[Michael Sulz]

Hallo Christian,

vielen Dank, das du deine Lösung hier gepostet hast

[Dirk Schlarmann]

Hallo Christian,

vielen Dank. Das ist die Lösung.

[Stephan Schulte]

Hallo Christian,

besten Dank für deine Lösung! Ich gehe davon aus, das viele CRM-Admins das Problem während der UR11 Installation zunächst gar nicht bemerken, da der Schluß-Hinweis auf den "fehlerhaften DB-Update bei einigen Organisationen" nicht unbedingt ins Auge springt. Mir ist das Problem erst bei der Versionsanzeige per "Info" im IE-Client aufgefallen, da hier die Abweichung angezeigt wird.
Nach IE-Fehler-Recherche bin ich schnell auf deine Lösung gestoßen die das Problem behoben hat.

Beste Grüße,
Stephan

[chilly]

Guten morgen,

ich wolle nachfragen, ob es bezüglich dieses Issues eine offizielle Mitteilung von Microsoft gibt? Bisher habe ich als Ergebnis meiner Suche immer nur Hinweise auf dieses Forum gefunden.

[Michael Sulz]

Hallo,

nein, eine offizielle Mitteilung von Microsoft gibt es dazu meines Wissens nicht.

Ich habe das mal bei Connect reingestellt:
https://connect.microsoft.com/dynamicss ... -with-ru11

[CPAG-HH]

Vielen Dank.
Klappt mit dem Fix

[enzi]

Ich habe genau das gleiche Problem unter UR 12.
Das Fix wirkt da aber nicht.

[Michael Sulz]

Hallo,

und erst einmal herzlich willkommen in unserem Forum

Der Fix ist auch nur für das RU 11, nicht für das RU12.
Welchen Fehler bekommst du denn, wenn du das RU12 einspielen möchtest?

[enzi]

Hallo Michael,

DANKE für Deine Rückmeldung.
Ich gehe davon aus, dass das Organisations-Update beim UR11 nicht durchgeführt wurde, weil der gleiche Fehler auftrat wie hier beschrieben.
Wir haben das aber nicht bemerkt und haben das UR12 installiert und erst jetzt im Bereitstellungsmanager festgestellt, dass die Organisation nicht up-to-date ist.
Ich habe eine Test- und eine Echt-Umgebung. In der Test-Umgebung erhalte ich die folgende Meldung beim Update der Organisation:

23:20:57| Info| Setting organization state. New state = Failed
23:20:57| Error| Ausnahmefehler beim Aktualisieren der Organisation (Id=a9751e9d-90a6-406b-85f9-68a96e54b4b9):
System.Exception: Fehler bei der Aktion Microsoft.Crm.Tools.Admin.InstallDatabaseUpdatesAction. ---> System.Data.SqlClient.SqlException: Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.
Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.
Die Anweisung wurde beendet.

Beim Versuch das Organisations-Update im Bereitstellungsmanager in der Echt-Umgebung durchzuführen, erhalte ich eine andere Fehlermeldung:
Der SQLSERVERAGENT-Dienst ("SQLSERVERAGENT") wird auf dem Server *SQL-Server* nicht ausgeführt.
Der Dienst läuft aber. Alles sehr merkwürdig.
Die Anwender hatten unter UR11 ohne Organisations-Update keine Probleme.
Jetzt unter UR12 schon - Bsp.: Zuweisen von Besitzern funktioniert gar nicht mehr.
Ist möglich ein Backup des CRM-Servers zurück auf UR 11 wiederherzustellen?
Hast Du so etwas schon einmal gemacht?
SQL-Backup Wiederherstellung macht keinen Sinn, da zuviel Zeit seit UR11 vergangen ist.
Ich habe mir überlegt, dass durch das fehlende Update der Organisation die Datenbank ja von beiden Updates nicht betroffen war bzw. berührt wurde, weil das ja fehlgeschlagen ist.
So hätte ich den Zustand wie hier beschrieben und könnte das Fix anwenden und danach UR12 erneut installieren.
DANKE.

[tlam]

Hallo enzi,

ich bin gespannt, ob deine Idee funktioniert. Ich habe bei einem Kunden von UR8 auf UR12 erhöht und auch deinen erstgenannten Fehler erhalten.
Also habe ich UR12 wieder deinstalliert, das obige Script von christian.mueller ausgeführt und anschließend erstmal UR11installiert. Gleiches Problem, gleiche Fehlermeldung.
Danach habe ich UR11 wieder deinstalliert und mal UR10 probiert. Gleiches Problem, gleiche Fehlermeldung.
Vermutung: UR12 hinterlässt Spuren, deshalb läuft anschließend das DB-Update sowohl für UR10 als auch für UR11 schief.

Inzwischen ist beim Kunden wieder UR12 drauf, die Datenbank zeigt halt noch die alte Versionsnummer. So ein Mist...

[TomDabbelju]

Hallo,

wir haben bei uns dasselbe Problem. Ich konnte mittlerweile einschränken, an welchen Befehlen es scheitert (dank SQL-Profiler):
Zuerst werden drei Tabellen geleert:

Code: Alles auswählen

delete TimeZoneLocalizedNameBase
delete TimeZoneRuleBase
delete TimeZoneDefinitionBase


Anschließend werden diese wieder befüllt. Dabei werden zwei Befehle nicht ausgeführt:

Code: Alles auswählen

insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
      StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
      DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
   values ( getutcdate(), getutcdate(), 12, '2012/07/20', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '546D7620-34E9-4565-AD10-72BA30486C37', 0,
         0, 0, 0, 0, 0, 0, 0, 0,
         -60, 0, 0, 0, 0, 0, 0, 0)
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
      StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
      DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
   values ( getutcdate(), getutcdate(), 12, '2012/08/19', 'A57C8407-74AF-47f0-B1D8-86575C134EC0', '86F4ACFB-3E69-474E-AAAF-238419C38801', 0,
         0, 0, 9, 5, 0, 3, 0, 0,
         -60, 0, 4, 5, 0, 2, 0, 0)

Hier sind Tag und Monat falsch rum, das fällt bei den anderen INSERTS nur nicht auf, da hier immer 'xxxx/01/01' verwendet wird. D.h. mit dem weiter oben genannten Befehl werden diese Zeilen zwar korrekt eingefügt, was aber aufgrund des Leeren der Tabellen nichts bringt.

Vor Ausführung dieser Befehle wird übrigens u.a.

Code: Alles auswählen

set language Deutsch
set dateformat dmy
set datefirst 1

ausgeführt.

Die DB ist auf Deutsch eingestellt, CRM ist ebenfalls deutsch, die DB-Version steht aktuell bei 05.00.9690.2838 (RU11). Die Frage wäre nun, ob diese Werte / Befehle irgendwo hardcoded stehen, oder in einer Daten stehen (hab' aber selbst mit Volltextsuche nichts finden können), oder ob man den ehler ggf. durch irgendwelche Einstellungen umgehen kann (Format in den CRM-Systemeinstellungen ändern hat leider nicht geholfen ).

Wir hatten das Problem übrigens auch schon beim Update von RU10 auf RU11, und da hat der Befehl geholfen. MS hat aber anscheinend im RU12 die Aktualisierung dieser Tabellen grundlegend geändert und ist dabei mit den Datumsformaten durcheinander gekommen.

Nachtrag (MIT LÖSUNG !!!!!!!):
Die 'Volltextsuche' in Windows ist absolut unbrauchbar. Hab' zwar nun mit einem eigenen Tool eine alte sql-Befehlssammlung im CRM-Programmordner gefunden, eine Änderung hier brachte aber keine Besserung.

Habe dann nochmal das RU12 gestartet. Während der Installation des RU12 befindet sich im temp-Ordner des ausführenden Benutzers (AppData/Local/temp) unter "Actions_Org\Install" die Datei "InstallTimeZoneInvariant.sql". Hier stehen die 'fehlerhaften' Einträge (suchen nach '2012/07/20', stehen direkt untereinander). Wenn man diese Datei bei erscheinen des 1. Dialogs bearbeitet und erst dann die Installation fortführt .... BRINGTS GARNIX.
Aber mit Hilfe des Dateinamens auf C alles durchsuchen lassen und nochmal 7 Kopien davon gefunden (WTF ....?). Alle angepasst, danach ging das Update.
Was für ein ,..........

[Michael Sulz]

Hallo,
ich habe mal den Titel des Beitrages präzisiert. Der Artikel beschäftigt sich mit Problemen beim Einspielen des RU11, nicht des RU12!

[enzi]

Hi TomDabbelju,

erst einmal vielen Dank für das Teilen Deiner Erkenntnisse...

Habe dann nochmal das RU12 gestartet. Während der Installation des RU12 befindet sich im temp-Ordner des ausführenden Benutzers (AppData/Local/temp) unter "Actions_Org\Install" die Datei "InstallTimeZoneInvariant.sql". Hier stehen die 'fehlerhaften' Einträge (suchen nach '2012/07/20', stehen direkt untereinander). Wenn man diese Datei bei erscheinen des 1. Dialogs bearbeitet und erst dann die Installation fortführt .... BRINGTS GARNIX.
Aber mit Hilfe des Dateinamens auf C alles durchsuchen lassen und nochmal 7 Kopien davon gefunden (WTF ....?). Alle angepasst, danach ging das Update.
Was für ein ,..........

Habe die Dateien bei der Suche über C:\ gefunden.
Allerdings war nicht in jeder dieser 7 Stück '2012/07/20' enthalten, sondern nur in 4.
Weiterhin finde ich beim Neustarten des Organisations-Update nicht den beschriebenen Ordner unter temp des ausführenden Benutzers (AppData/Local/temp) unter "Actions_Org\Install"...

[Dirk Schlarmann]

lasst uns über UR12 hier weiterschreiben: http://www.msdynamics.de/viewtopic.php?f=60&t=19095