[gelöst]Fehler beim Update auf 2013R2 CU6

[rainergaiss]

Hallo,

wir haben ein "Langlaufprojekt" bei einem Kunden, der derzeit noch eine 3.70-Version (technisch 5 SP1) mit nativer DB im Einsatz hat. Als wir angefangen haben, neu zu entwickeln, war gerade die 2013R2 CU 6 die aktuellste Version. Zum Upgrade haben wir damals zunächst eine SQL-Version erstellt, den Upgrade auf 2009 und weiter auf 2013R2 gemacht, was einwandfrei funktionierte. Allerdings haben wir damals nur einen Mandanten zum Update herangezogen. Genutzt haben wir ausschließlich die aktuellen Toolkits.

Nachdem sich der Datenbestand bei dem Kunden stark verändert hat, habe ich nun eine neue Konvertierung gemacht, allerdings mit allen 4 Mandanten. Bis zur 2009R2-Version lief alles optimal, ich habe eine saubere und stabile Version, die allerdings jetzt weiter konvertiert werden muss auf die 2013R2. Gekommen bin ich (schon im 2. Versuch) jeweils bis zu dem Punkt, wo ich in die "nackte" Datenbank, also die nur mit den Tabellen, unsere aktuellen Objekte einlese. Das funktioniert noch, doch sobald ich versuche, die Datenbank mit dem Client zu öffnen (der Dienst läuft sauber und wird auch im Dev.Env. erkannt) hängt das Ganze. Damit hat dann die Übung ein Ende, denn die DB lässt sich nicht mehr ansprechen, weder über NAV noch über das Management Studio. Es lässt sich nicht genau nachvollziehen, was passiert ist, es gibt sowohl Fehlermeldungen über ein Berechtigungsproblem (was eigentlich nicht sein kann, da selbst der DBO über das Management Studio keinen Zugriff mehr erhält), aber auch über einen Timeout. Das einzige, was sicher ist, ist, dass die DB offensichtlich hinüber ist.

Der einzige Unterschied zu dem letzten Update, das funktionierte, ist also, dass wir nun 4 statt einem Mandanten haben. Meine persönliche Meinung ist, dass wir auf ein höheres CU oder die 2015-Version gehen sollten, aber leider scheut die Projektleitung den Aufwand, da die DB eine hohe Zahl von individuellen Anpassungen und AddOns enthält, die dann wieder nachgezogen werden müssten.

Ich habe das Ganze etwas "ausschweifend" beschrieben, finde aber, dass diese Hintergrundinformationen wichtig sind.

Hat jemand ähnliche Erfahrungen?

Gruß Rainer

Zuletzt geändert von rainergaiss am 12. März 2015 13:14, insgesamt 1-mal geändert.

Es lässt sich nicht genau nachvollziehen, was passiert ist, es gibt sowohl Fehlermeldungen über ein Berechtigungsproblem (was eigentlich nicht sein kann, da selbst der DBO über das Management Studio keinen Zugriff mehr erhält), aber auch über einen Timeout. Das einzige, was sicher ist, ist, dass die DB offensichtlich hinüber ist.

Hi Rainer,

kannst du uns die Fehlermeldungen posten?
* Ist die SQL-DB sauber? Ich hatte den Fall, dass ein Kunde einen Datenbanktrigger angelegt hatte, wodurch die Konvertierung nicht funktionieren wollte.
* Sind die Upgrade-Objekte gelöscht worden?
* Ist die CU Checkfields (aus der SQL-Migration) gelöscht worden?
* alles kompiliert?
* sync-navtenant ausgeführt?

Meine persönliche Meinung ist, dass wir auf ein höheres CU oder die 2015-Version gehen sollten, aber leider scheut die Projektleitung den Aufwand, da die DB eine hohe Zahl von individuellen Anpassungen und AddOns enthält, die dann wieder nachgezogen werden müssten.

Die Installation technisch auf das letzte CU hochzuziehen ist mehr als verpflichtend! Es müssen dann auch keine (oder max. für sehr wenige externe Komponenten, weiß ich nicht im einzelnen) Add-Ons oder Objekte geändert werden.

Und wie schon geschrieben, die Fehlermeldung wäre mehr als wichtig. Es ist auch schwer zu ermitteln, warum die Datenbank nicht über das SQL Server Management Studio im Zugriff ist, es sei denn, sie befindet sich (noch) im Single User Modus und ein Prozess greift noch darauf zu (was wahrscheinlich ist).

Beim Öffnen hängt es... Kommt noch eine Meldung, eine Abfrage zur Konvertierung? Wann hängt der Client genau, welche Schritte (im DevEnv Client) hast du bis dahin bereits ausgeführt?

Zunächst mal vielen Dank so weit!

Ich habe zwischenzeitlich auch in mibuso einen Thread gefunden, der mein Problem beinhaltet: http://www.mibuso.com/forum/viewtopic.php?f=32&t=60574. Konkret geht es dabei um die Meldung

"Also happened to me during Upgrade of NAV 2009 R2 database to NAV 2013 R2.

Initially, while importing Customised NAV 2013 R2 Object set I got:
The Following SQL Error was unexpected.
Invalid Column Name 'Authentication Email'
Invalid column name 'Authentication Object ID'"

Ich habe mir einmal den Thread und alle Links genauer angesehen. Das ist mein bisheriger Ablauf:

Ich starte mit einer absolut sauberen 2009R2-SQL-Datenbank, die alle Objekte dieser Version enthält und dazu noch die nachzuziehenden DB-Änderungen. Diese Version ist über jeden Zweifel erhaben.
Dann importiere ich die 2009 R2 -> 2013 R2 Upgrade Objecte und führe den Data Transfer in allen Mandanten aus. Das funktioniert noch einwandfrei.
Dann werden alle Objekte außer Tabellen gelöscht --> ok.
Dann öffne ich die DB mit dem NAV 2013 Developement Environment und konvertiere sie. Das dauert rund zweieinhalb Stunden und funktiooniert perfekt.
Dann öffne ich die DB mit dem NAV 2013 R2 Developement Environment und konvertiere sie. Das dauert ein paar Sekunden.
Dann kompilere ich die System-Tabellen. Auch ok.

So weit, so gut.

Als Quintessenz aus den mibuso-Einträgen und der URL http://www.dynamics.is/?p=1840 müsste ich nun den Timeout des SQL-Servers von 20 bzw. 30 Minuten auf 12 oder sogar 24 Stunden ändern. Ich weiß allerdings nicht wie (da gibt es irgendwo eine CustomerSettings.Config).

Dann müsste ich im Developement Environment die Option “Prevent data loss from table changes” auf “No” setzen. Das habe ich auch nicht getan.

Dann habe ich meine 2013R2-Objekte importiert. Das hat funktioniert.

Dann hätte ich aus der PowerShell, Sync-NAVTenant ausführen sollen, was ich nicht getan habe. Stattdessen habe ich die Objekte fehlerfrei kompiliert.

Und da verließen sie ihn: Ich konnte weder die Datenbank mit dem Dienst verbinden, noch NAV starten und den Server auswählen. Entweder kamen die Fehlermeldungen wie oben oder die Meldung, dass kein Dienst gefunden wurde. Im mibuso-Thread wird noch darauf hingewiesen, dass im Hintergrund noch ewig Schlüssel aufgebaut würden, was man sehen könne, wenn man das Service Tier beobachtet. Leider weiß ich nicht so richtig, wie man das macht.

Wenn ich an dieser Stelle weiter käme, wäre der Rest wahrscheinlich auch kein Problem mehr.

Ich bereite gerade noch einmal eine Datenbank vor, wo ich alles bis zum Setzen des Timeouts durchziehe. Für den Rest hoffe ich dann einmal auf Hilfe. Ich bin jetzt allerdings erst einmal bis zum 24.2. im Urlaub und werde in dieser Zeit leider nicht antworten können.

Gruß Rainer

Hi Rainer,

den SQL Command Timeout kannst du direkt am NST über die NAV 2013R2 Administration (Powershell snappin) hochsetzen

oder in der CustomSettings - die liegt normalerweise hier:

"C:\Program Files\Microsoft Dynamics NAV\71\Service\CustomSettings.config"

beim Hinweis, dass kein Dienst gefunden wurde, musst du die Meldung mal mit "NEin" bestätigen und dann versuch mal manuell die Parameter des Dienstes mitzugeben - vielleicht hat er sich einfach die falschen
Daten geladen, der DIenst ist nicht gestartet oder oder oder.

Ich wünsche dir ersteinmal einen erholsamen Urlaub!

...den Timeout des SQL-Servers von 20 bzw. 30 Minuten auf 12 oder sogar 24 Stunden ändern. Ich weiß allerdings nicht wie (da gibt es irgendwo eine CustomerSettings.Config).

Über die Dynamics NAV Management Console, Reiter "General", Einstellung "SQL Command Timeout" (von 00:30:00 auf 12:00:00).

Dann müsste ich im Developement Environment die Option “Prevent data loss from table changes” auf “No” setzen. Das habe ich auch nicht getan.

Werden neue Tabellenobjekte importiert, bei denen Felder gegenüber dem vorherigen Stand Fehlen, ist es möglich, dass es nicht ohne diesen Weg geht. In der Entwicklungsumgebung unter Optionen also auf "No" stellen, für diesen Schritt bis nach dem Synch. Teste aber vorher bitte nochmals mit allen Schritten ohne diese Option.

Dann habe ich meine 2013R2-Objekte importiert. Das hat funktioniert.

Das funktioniert gut, die Synchronisation der Tabellen-Schemata kann/wird allerdings dann ersteinma nicht durchgeführt.

Dann hätte ich aus der PowerShell, Sync-NAVTenant ausführen sollen, was ich nicht getan habe. Stattdessen habe ich die Objekte fehlerfrei kompiliert.

Passt, aber danach dann die Synchronisation ausführen (Sync-NavTenant) in der PowerShell als Administrator geöffnet.

Und da verließen sie ihn: Ich konnte weder die Datenbank mit dem Dienst verbinden, noch NAV starten und den Server auswählen. Entweder kamen die Fehlermeldungen wie oben oder die Meldung, dass kein Dienst gefunden wurde. Im mibuso-Thread wird noch darauf hingewiesen, dass im Hintergrund noch ewig Schlüssel aufgebaut würden, was man sehen könne, wenn man das Service Tier beobachtet. Leider weiß ich nicht so richtig, wie man das macht.

Es ist besser den SQL Server per SQL Server Profiler zu beobachten. Das schlimmste ist, den NAV Server hart zu beenden während die Konvertierung/Synchronisation läuft.

Der folgende Link enthält beschreibt dein Szenario detailliert:
Link.

Dann hätte ich aus der PowerShell, Sync-NAVTenant ausführen sollen, was ich nicht getan habe. Stattdessen habe ich die Objekte fehlerfrei kompiliert.

Passt, aber danach dann die Synchronisation ausführen (Sync-NavTenant) in der PowerShell als Administrator geöffnet.

Vielleicht war auch der Tabellenhappen zu groß:

For big batch of FOB files that are making a high number of table modifications, be sure to have this tested on a safe staging environment and import, where possible, the Table Objects in smaller chunks and synchronize them after importing every single chunk of Microsoft Dynamics NAV objects.

aus: http://blogs.msdn.com/b/nav/archive/2014/03/27/table-synchronization-paradigm-in-microsoft-dynamics-nav-2013-r2.aspx

Die Tabellen via Powershell mit jeweils anschließendem Sync-NavTenant in kleinen Häppchen zu importieren ist sicherer.
Importfunktionen: http://www.msdynamics.de/viewtopic.php?f=17&t=25536

Hallo Kai,

ich glaube nicht, dass die Menge der Änderungen zu riesig ist, denn es handelt sich eigentlich nur um die Differenzen zwischen der 2009 und der 2013R2. Alle anderen Tabellen bleiben unverändert. Außerdem hat das Ganze ja auch schon mal funktioniert.

Mich würde interessieren, ob das Update von 2009R2 auf 2015 (dieses neue Updateverfahren) auch noch die ganzen Probleme mit sich rumschleppt.

Wenn mein nächster Versuch wieder scheitert, werde ich mal deine "Häppchenweise-Lösung" probieren.

Vielen Dank!

Rainer

Außerdem hat das Ganze ja auch schon mal funktioniert.

Wenn der erste Test für einen Mandant war, jetzt aber 4 Mandanten verarbeitet werden müssen, dann ist das schon ein großer Unterschied. Der SQL-Server legt ja pro Mandant jeweils eine separate Tabelle an, die Timeoutgefahr beim Synchronisieren dürfte somit höher sein.

Die 3 anderen Mandanten haben alle nur ein paar Sätze, fallen also nicht wirklich ins Gewicht. Denke ich zumindest. Mir ging es vorhin nur darum, ob es möglicherweise einen Unterschied macht, wenn einer oder mehrere Mandanten vorhanden sind, weil die Mandantenwahl ja jetzt nur noch im Client stattfinden kann.

Gruß

Rainer

Um bei R2 die Objektmetadaten mit den Servertabellen abzugleichen ist auch dieses Tool verfügbar:
Database check tool for Microsoft Dynamics NAV 2013 R2

Ich habe hier einen Sammelthread zum Thema Schemaänderungen gestartet, u.a. um deutlich zu machen, dass in R2 das Kompilieren im Gegensatz zu den Vorgängerversionen dafür nicht mehr ausreicht.

[rainergaiss]

Vielen Dank zunächst für eure Hilfe, dank derer ich jetzt schon ein Stück weiter bin.

Beim Sync-NAVTenant habe ich jetzt folgende Fehlermeldung bekommen:

Sync-NAVTenant : Der folgende SQL-Fehler war nicht erwartet.
In der Datenbank ist bereits ein Objekt mit dem Namen 'CRONUS AG$Hermes lfd_Paketnummer' vorhanden.
In Zeile:1 Zeichen:1
+ Sync-NAVTenant -ServerInstance Servicename
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (0:Int32) [Sync-NAVTenant], FaultException`1
+ FullyQualifiedErrorId : MicrosoftDynamicsNavServer$Servicename,Microsoft.Dynamics.Nav.Management.Cmdlets.SyncNavTenant

Ich vermute, dass die Fehlermeldung deshalb erfolgt, weil diese und einige weitere Tabellen nicht in der Lizenz enthalten sind aber aus der alten Version übernommen wurden. Sie sind leer und werden nicht gebraucht. Nun habe ich versucht, sie im Dev.Env. zu löschen, was ich wahrscheinlich besser nicht getan hätte. Erfolg: Die Eieruhr. Keine Ahnung was ich jetzt am besten machen soll bzw. wie weit ich zurück muss um neu aufzusetzen. Weiß jemand Bescheid?

Zuletzt geändert von rainergaiss am 10. März 2015 16:47, insgesamt 1-mal geändert.

Zwei Methoden zum Löschen unnötiger Objekte außerhalb der Lizenz haben wir in diesem Thema:
viewtopic.php?f=66&t=25717

Hallo Kai,

danke für den Tipp mit dem Killerobjekten. In dieser Situation ist es nur leider schon zu spät.

Das SQL-Management-Studio bietet mir nach diesen Informationen in der 2013R2 keine Lösung mehr (obwohl diese Tabellen leer sind), außerdem habe ich schon die Eieruhr, d.h. wenn ich jetzt das Dev.Env. abbreche ist die Datenbank mit hoher Wahrscheinlichkeit nur noch für den Orkus.

Ich sehe als einzige Möglichkeit zurückzugehen auf die 2009R2 und in der Hoffnung, endlich alle überzähligen Tabellen zu erwischen, diese mit dem SQL-Management-Studio zu löschen, so wie ich es mit den vielen anderen auch schon getan habe. Oder hast du noch einen Gedankenblitz, der mir die vielen Stunden ersparen könnte?

Gruß

Rainer

Oder hast du noch einen Gedankenblitz, der mir die vielen Stunden ersparen könnte?

Nein, da würde ich auch gar kein Risko eingehen., wenn ich gar nichts mehr normal ansprechen lässt. Zurück auf Start und als Lehrgeld verbuchen. Der ganze Bereich ist leider wesentlich empfindlicher geworden, u.a. deswegen habe den FAQ-Artikel ja aufgesetzt.

Hallo,

es gibt im NAV 2013 R2 Client unter Extras\Optionen die Option "Datenverlust durch Tabellenänderung verhindern", die ist defaultmäßig auf Ja (Ich denke das Entspricht in NAV2015 Der "Check"-Option). Evtl. solltest du die Option mal auf NEIN setzten, damit der Server diese Objekte wegräumt (Entspricht in NAV2015 der Force- Option)

Gruß, Fiddi

Ich fürchte nur, dazu ist es jetzt zu spät. Ich habe das Dev.Env. abgebrochen, die Option auf nein geändert und das Cmdlet noch einmal gestartet. Es war sofort fertig und hat auch offensichtlich nichts getan. In welches der beiden Mandantenfelder in den Optionen muss ich eigentlich den Mandanten eintragen wenn ich die Page104002 aufrufen will?

Die Datenbank scheint nicht mehr brauchbar zu sein.

Das Problem ließ sich nun auf eine ganz einfache Art lösen: Wenn man vor dem Einlesen der 2013R2-Objekte einen zusätzlichen Sync-NAVTenant durchführt lässt sich danach alles problemlos einlesen.