Startseite > CRM 2011, Fehlersuche, Update > RU11 kann nicht auf der Datenbank eingespielt werden

RU11 kann nicht auf der Datenbank eingespielt werden

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 (0x80131904): 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!).

Schlagwörter: , ,
  1. Tristan Hager
  2. 5. November 2012 um 12:51

    Und was mache ich, wenn im Deployment Manager nach der Installation (und dem geschilderten Problem) keine Updates verfügbar sind und immernoch die alte Version (von vor dem UR 11) angezeigt wird?

    • 5. November 2012 um 13:32

      dann einmal alle CRM Dienste beenden und neu starten, dann sollte das Update im Deployment Manager angezeigt werden. Wenn nicht, hat es wahrscheinlich einen anderer Fehler beim Update gegeben, dann einmal das Protokoll überprüfen.

  3. 6. November 2012 um 09:31

    habe das UR 11 nochmal manuell eingespielt – jetzt lief alles durch. Danke für die Hilfe

  1. No trackbacks yet.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: