In der Version 2 des RU11 für Microsoft Dynamics CRM 2011 gibt es einen Fehler der dazu führt, das zwar das Serverupdate durchgeführt werden kann, das Update auf der CRM Datenbank aber nicht durchgeführt wird.
Ihr seht dann im Deployment Manager, das die Datenbank immer noch auf der vorher eingespielten Updateversion ist.
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 (0×80131904): Bei der Konvertierung eines varchar-Datentyps in einem datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.”
Aktuell ist mir nur eine unsupportete Lösung für dieses Problem bekannt, das freundlicherweise von Christian.Mueller hier gepostet wurde.
Anbei die wichtigsten Teile aus seinem Post:
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).
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!).