Upgrade 2009R2 --> 2015CU6 Dimensionen

Hallo zusammen,

ich bin am verzweifeln. Ich bin an einem Upgrade von 2009 nach 2018 dran. Ich habe alle Schritte von 2009 bis 2015 erfolgreich durchlaufen und stehe nun vor dem Data Upgrade auf 2015. Hier hakt es.

Der Kunde hat drei Mandanten. Zwei vernachlässigbar kleine und einen großen mit über einer Million Sätzen in den Tabellen 355 bis 357. Der Aufenthalt in den einzelnen Mandanten betrug weniger als eine Minute bei den Kleinen und anfangs 3 Stunden bei dem großen. Bei den Kleinen wurden einige wenige Dimension-Sets erzeugt, beim Großen keine. Beim ersten Durchgang konnte ich herausfinden, was in den Mandanten die unterschiedlichen Fehlermeldungen bedeuteten und sie entsprechend beheben. Dabei war es so, dass es Dimensionen ohne Werte u.ä. gab. Das habe ich dann behoben.

Im nächsten Durchgang habe ich bei den neuen noch weitere Meldungen bekommen, die ich ebenfalls erfolgreich korrigieren konnte. Für das Upgrade des großen Mandanten brauchte es nun schon 4 Stunden und endete mit der Meldung
: 'Dimension Value ID' muss in 'Dimension Set Entry' einen Wert
enthalten: 'Dimension Set ID=0, Dimension Code=AKTENZEICHEN'.
Der Wert darf nicht null oder leer sein.

Daraufhin baute ich die Änderung aus dem Link http://www.msdynamics.de/viewtopic.php?f=66&t=27011#p110294 ein. Nun lief das Ganze 6 Stunden. Am Ende hatte ich von den 3 Mandanten diese Fehlermeldungen:

SessionId : 20413
CodeunitId : 104055
FunctionName : StartUpgrade
CompanyName : xy Beteiligungs GmbH
StartTime : 07.05.2019 11:12:40
Duration :
State : Failed
Error : Fehler bei einem Aufruf von
System.Data.SqlClient.SqlCommand.CommandText mit folgender
Meldung: Das Objekt mit dem Typ "System.String" kann nicht in
den Typ "System.Int32" konvertiert werden.

SessionId : 20413
CodeunitId : 104055
FunctionName : StartUpgrade
CompanyName : xy GmbH_Co KG
StartTime : 07.05.2019 11:12:43
Duration :
State : Failed
Error : 'Dimension Value ID' muss in 'Dimension Set Entry' einen Wert
enthalten: 'Dimension Set ID=0, Dimension Code=AKTENZEICHEN'.
Der Wert darf nicht null oder leer sein.

SessionId : 20413
CodeunitId : 104055
FunctionName : StartUpgrade
CompanyName : xy Verw.-GmbH
StartTime : 07.05.2019 17:14:37
Duration :
State : Failed
Error : Fehler bei einem Aufruf von
System.Data.SqlClient.SqlCommand.CommandText mit folgender
Meldung: Das Objekt mit dem Typ "System.String" kann nicht in
den Typ "System.Int32" konvertiert werden.

Unmittelbar nach der Konvertierung konnte ich gestern Abend in der Tabelle 480 im richtigen Mandanten über eine Million Datensätze feststellen. Heute Morgen musste ich feststellen, dass die Datensätze wieder verschwunden waren.

Jetzt meine Fragen:
Wie kann ich überhaupt feststellen, wann der Upgrade-Prozess hält und beim nächsten Schritt weitermacht?
Kann der Prozess nach Fehler auch direkt mit dem nächsten Mandanten weitermachen?
Wie kann ich das Ganze debuggen?
Wie ist das technisch gelöst, dass die Codeunit nach einem Error weiterläuft?
Gibt es eine vernünftige Beschreibung dieses Prozesses?
Wie kann ich herausfinden, wo die Fehler aus der Ausführung der SQL-Kommandos entstehen?
Und natürlich nicht zuletzt: Wie kann ich die CU dazu bringen durchzulaufen und dabei die erzeugten Daten zu behalten?

Bitte helft mir vor meiner letzten Verzweiflungstat!

Gruß
Rainer

Hallo,

ich weiß es jetzt nicht mehr genau,aber beim Update der Dimensions IDs werden SQL-Scripte benutzt. Kann es sein das da ein Textfeld einem Integer zugewiesen werden soll.

Ein Options-Feld wäre ein schöner Kandidat dafür. Man übergibt den Optionswert mit FORMAT, was einen Text erzeugt, der dann im SQL einem Integer zugewiesen werden soll.

Gruß Fiddi

Hallo Fiddi,

da habe ich einen Tipp in https://forum.mibuso.com/discussion/664 ... to-nav2015 erhalten, der mir vermutlich das Problem mit den Kleinen lösen kann.

Aber ich habe da ja noch ganz andere Probleme mit 6 Stunden Laufzeit und dem anschließenden Wieder-Verschwinden der Daten (Rollback als Ursache?) und ohne Debug-Möglichkeiten ...

Ich hatte das Laufzeitproblem auch (wir haben nach 20 Stunden abgebrochen). Nach einer Anpassung hat das ganze Update nur noch 4 Stunden benötigt.

Aber das zu lösen war irgendwie mehrstufig. Aber wie genau weiß ich jetzt aus dem Kopf auch nicht mehr.

Gruß Fiddi

Die 6 Stunden wären für mich ok! Ich frage mich nur, warum nach dem Ende die Tabelle 480 gefüllt ist, und am nächsten Morgen ist sie dann wieder leer. Das kann doch nur ein Rollback sein?

"Dimension Value ID" ist ja ein neues Feld in der Tabelle Dimension Value. Du müsstest dir mal den Code anschauen wo diese erzeugt werden. Ich habe bei den bisherigen Migrationen von NAV 2009 R2 in neuere Versionen dabei keine Probleme gehabt. Ich bin aber immer als Zwischenschritt über NAV 2013 / 2013 R2 gegangen, nicht NAV 2015, wenn ich das richtig in Erinnerung habe.

Ich habe auch schon viele Upgrades von 2009 her gemacht, und bisher hat es immer funktioniert. In diesem Fall sind fehlerhafte Daten die Ursache, dass es nicht geht. Und dabei ist der Schritt von 2009 auf 2015 sicherer als über 2013, da einiges in 2013 ziemlich buggy war, was in 2015 funktioniert. Außerdem werden die Datensätze über SQL-Statements erzeugt, sind also schwer oder nicht zu debuggen. Ich muss also weiter suchen, dauert halt nur ewig lang ...

...das ist für mich das Argument über NAV 2013 (oder R2 ?) zu gehen wo die Logik in NAV abläuft und ich sie als jemand der keine Ahnung von SQL hat verfolgen und korrigieren kann...

Falsch! 2013 und R2 generieren ebenfalls SQL-Befehle.

Oha! Dann ist ja gut dass ich da noch keine Probleme bekommen habe. Ist mir aber in den Upgrade Codeunits usw. nicht aufgefallen dass da Aufrufe von externen Programmen dabei gewesen wären. Interessant!

...deswegen ist die 2015 auch stabiler als die 2013 (wo das der erste Versuch war).

Ist aber so, ist in einer eigenen Codunit, die heißt auch irgendwie mit SQL (ist übrigens sehr interessant für eigene Projekte, die auf externe SQL-Server zugreifen)

Hallo Rainer,

wir kämpften in den letzten Tagen ebenfalls mit einer Migration von NAV2009 R2 auf BC (mit dem Zwischenschritt auf NAV2015).
Bei der Migration von NAV2009 R2 auf NAV2015 hatten wir ebenfalls Probleme wegen den Dimensionen.
Bei älteren Buchungen wurden teilweise Dimensionswerte verwendet, die irgendwann im Laufe der Jahre gelöscht wurden.
Wir konnten die Upgrade-Probleme schließlich klären und lösen, indem wir bei der betreffenden Upgrade-Codeunit den Subtype von "Upgrade" auf "Normal" gestellt und die Codeunit einmal manuell ausgeführt hatten.
Zuvor hatten wir an ein paar Programmstellen Breakpoints gesetzt und so die Codeunit debuggen können.
Den Tipp dazu habe ich auf mibuso gefunden.

Hallo Rainer,

hast du das SQL-Script mal ausgeführt?
https://saurav-nav.blogspot.com/2014/05/nav-2013-nav-2013-r2-comman-issue.html

Bisher lag es bei uns immer an gelöschten Datensätzen - die wir damit hergestellt und geblockt haben.
Weitehrin die Frage:
lässt du den DataUpgrade seriell oder parallel laufen?
Ich stelle immer auf seriell, da es mir schon einige male auf die Füße gefallen ist.

Ein letztes Mal hallo zusammen,

es hat geklappt! 24 Mio. Datensätze in 12:20 Stunden, also ca. 2 Millionen Sätze pro Stunde.

Die Erkenntnis: Den Upgrade immer mit "Bei Fehler fortfahren"machen, dann wird genau die Funktion übersprungen, in der der Fehler passiert. Die kann man nachher manuell korrigieren. In meinem Fall war es halt blöd wegen des Rollbacks von Millionen Sätzen.

Die Frage parallel oder seriell muss immer mit parallell beantwortet werden, da sonst Fehler passieren können. In meinem Fall war es nicht tragisch, da neben dem großen Mandanten (>12:20) 2 sekr kleine ( < 1 min) zur Verfügung stehen. Bei seriell lässt es sich mit Glück auch debuggen, da dann die Session-ID. gleichbleibt.

Die Ausführung des erwähnten SQL-Skrpits war dann auch Teil der Lösung. Es fehlte genau ein Satz.

Vielen Dank euch allen. ich habe viel dabei gelernt.

Rainer

Unsere Erfahrung ist vorher aufräumen (viele kleine Skripte), und ausschliesslich seriell arbeiten lassen.

Hallo,

Unsere Erfahrung ist vorher aufräumen (viele kleine Skripte), und ausschliesslich seriell arbeiten lassen.

Das sehe ich ganz genauso:
1. Was nicht da ist, muss man nicht updaten, und man kann es vorher zu nicht zeitkritischen Zeiten erledigen.
2. Die serielle Ausführung ist prinzipbedingt notwendig, insbesondere dann, wenn mehrere Addons mit Updateroutinen vorhanden sind, die u.U. auf gleiche Tabellen zugreifen. Ansonsten kann es zu Locking- Problemen kommen (Wie z.B. Update NAV 2015-2018 mit akquinet- Zahlungsverkehr).

Gruß Fiddi

Die Frage parallel oder seriell muss immer mit parallell beantwortet werden, da sonst Fehler passieren können.

ich kann hier defintiv jens und fiddi nur zustimmen - ich nutze auch nur seriell (wie bereits erwähnt)

oops, das war ein Verschreiber - ich meinte natürlich auch nur seriell!! Vor allem bei meiner Konstellation (12 h + 1 min + 1 min). Und natürlich räume ich auch vorher mit Skripten auf.