[GELÖST]Einspielen von Update Rollup 11schlägt auf Datenbank
23. Oktober 2012 16:18
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?
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?
Zuletzt geändert von Dirk Schlarmann am 31. Oktober 2012 18:39, insgesamt 1-mal geändert.
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
24. Oktober 2012 12:21
Hallo Dirk,
welche UR Version hat die Datenbank, die du updaten möchtest?
welche UR Version hat die Datenbank, die du updaten möchtest?
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
24. Oktober 2012 15:03
Die Datenbank ist auf Stand UR 10v2.
Die Voraussetzung für Update Rollup 11 ist Update Rollup 6, oder?
Die Voraussetzung für Update Rollup 11 ist Update Rollup 6, oder?
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
24. Oktober 2012 16:07
ja, die Voraussetzung ist UR 6
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
25. Oktober 2012 08:52
Hallo,
wann hast du das RU vom Server geholt? Seit dem 23.10.gibt es ein v2 für das Serverupdate.
wann hast du das RU vom Server geholt? Seit dem 23.10.gibt es ein v2 für das Serverupdate.
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
25. Oktober 2012 09:35
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.
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.
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
25. Oktober 2012 11:59
Hallo,
bei uns tritt das selbe Phänomen auf.
Beim Anlegen einer neuen Organisation, bleibt selbst die neu angelegte Datenbank auf UR6.
bei uns tritt das selbe Phänomen auf.
Beim Anlegen einer neuen Organisation, bleibt selbst die neu angelegte Datenbank auf UR6.
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
25. Oktober 2012 14:43
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
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
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
26. Oktober 2012 08:07
Hallo Frank,
dann hilft eigentlich nur das Tracing einzuschalten und dann ein Update der Organisation durchzuführen.
dann hilft eigentlich nur das Tracing einzuschalten und dann ein Update der Organisation durchzuführen.
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
30. Oktober 2012 17:37
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
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
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
31. Oktober 2012 15:12
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
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
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
31. Oktober 2012 16:49
Hallo Christian,
vielen Dank, das du deine Lösung hier gepostet hast
vielen Dank, das du deine Lösung hier gepostet hast
Re: Einspielen von Update Rollup schlägt auf Datenbank fehl
31. Oktober 2012 18:38
Hallo Christian,
vielen Dank. Das ist die Lösung.
vielen Dank. Das ist die Lösung.
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
6. November 2012 11:09
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
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
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
21. November 2012 11:02
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.
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.
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
21. November 2012 11:27
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
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
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
8. Januar 2013 14:09
Vielen Dank.
Klappt mit dem Fix
Klappt mit dem Fix
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
5. Februar 2013 00:09
Ich habe genau das gleiche Problem unter UR 12.
Das Fix wirkt da aber nicht.
Das Fix wirkt da aber nicht.
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
5. Februar 2013 09:26
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?
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?
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
6. Februar 2013 00:33
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.
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.
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
6. Februar 2013 17:13
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...
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...
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
7. Februar 2013 22:31
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:
Anschließend werden diese wieder befüllt. Dabei werden zwei Befehle nicht ausgeführt:
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.
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 ,..........
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:
delete TimeZoneLocalizedNameBase
delete TimeZoneRuleBase
delete TimeZoneDefinitionBase
Anschließend werden diese wieder befüllt. Dabei werden zwei Befehle nicht ausgeführt:
- Code:
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:
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 ,..........
Re: [GELÖST]Einspielen von Update Rollup 11schlägt auf Daten
8. Februar 2013 09:39
Hallo,
ich habe mal den Titel des Beitrages präzisiert. Der Artikel beschäftigt sich mit Problemen beim Einspielen des RU11, nicht des RU12!
ich habe mal den Titel des Beitrages präzisiert. Der Artikel beschäftigt sich mit Problemen beim Einspielen des RU11, nicht des RU12!
Re: [GELÖST] Einspielen von Update Rollup schlägt auf Datenb
8. Februar 2013 12:02
Hi TomDabbelju,
erst einmal vielen Dank für das Teilen Deiner Erkenntnisse...
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"...
erst einmal vielen Dank für das Teilen Deiner Erkenntnisse...
TomDabbelju hat geschrieben:
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"...
Re: [GELÖST]Einspielen von Update Rollup 11schlägt auf Daten
8. Februar 2013 14:13
lasst uns über UR12 hier weiterschreiben: http://www.msdynamics.de/viewtopic.php?f=60&t=19095