[Gelöst] Clientabsturz bei Datenbank mit Addon-Objekten

Leider scheint NAV 2015 bei Objektimporten eher noch empfindlicher als die Vorgängerversionen zu sein.

Eine Datenbank, die "Demo Database NAV (8-0)" heisst , lässt sich aufrufen, eine andere, die ebenfalls aus dem gleichen Backup neu erstellt wurde, zusätzlich frisch importierte Addon-Objekte mit dem gleichen Build enthält und dann "NAV800DE_DEV_2015" heißt, bringt den Client zum Absturz, direkt beim Aufrufen. Die CustomSettings.Config-Datei im Ordner …/80/Service wurde dabei wie üblich angepasst.

Startprobleme in NAV 2013 R2 nach Wechsel der Datenbank hatte ich ja schon mal (Link), hier liegen aber andere Verhältnisse vor, dieses Mal schmiert der Dienst dabei auch nicht ab, dafür aber der Client . Der db_owner ist für die neue Datenbank auch gesetzt.

Letzte Info vor dem Fehler in der Ereignisanzeige.

Server instance: DynamicsNAV80
Tenant ID: default
Session type: RoleTailoredClient
Session ID: 1
Object Change Listener is listening on SQL Server 'KK-NB\NAVDEMO' in Database 'NAV800DE_DEV_2015'.

Erster Fehler:

Application: Microsoft.Dynamics.Nav.Client.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: Microsoft.Dynamics.Nav.Types.Exceptions.NavSqlDatabaseSyncException
Stack:
at Microsoft.Dynamics.Nav.Client.FormBuilder.BuilderSessionInitializer.Initialize()
at Microsoft.Dynamics.Framework.UI.UISession.Initialize()
at Microsoft.Dynamics.Nav.Client.WinClient.NavWinFormsClientSession.InitializeUISession()
at Microsoft.Dynamics.Framework.UI.Windows.ClientSessionBase.SetupSessions()
at Microsoft.Dynamics.Framework.UI.Windows.ClientSessionBase.InitCore()
at Microsoft.Dynamics.Nav.Client.WinClient.NavWinFormsClientSession.InitCore()
at Microsoft.Dynamics.Framework.UI.ClientSessionCore.Init()
at Microsoft.Dynamics.Framework.UI.Windows.ClientSessionBase.Run()
at Microsoft.Dynamics.Nav.Client.WinClient.NavClientErrorHandler.ExecuteAndCatchExceptions(System.Func`1<Int32>)
at Microsoft.Dynamics.Nav.Client.WinClient.ExceptionHandler.DoExecute(System.Func`1<Int32>)
at Microsoft.Dynamics.Nav.Client.WinClient.StartWinFormsClient.RunCore()
at Microsoft.Dynamics.Nav.Client.WinClient.StartWinFormsClient.Run(Boolean)
at Microsoft.Dynamics.Nav.Client.WinClient.StartWinFormsClient.RunAndDispose()
at Microsoft.Dynamics.Nav.Client.Program.ExecuteNormally(System.Func`1<Int32>)
at Microsoft.Dynamics.Nav.Client.Program.Main(System.String[])

Erst nach einem Neukompilieren aller Objekte war das Problem behoben (mit Synchronize Schema::Now-with validation). Nur die Addon-Objekte zu kompilieren (da noch mit mit Synchronize Schema::Later) war nicht ausreichend und führte immer noch zum Clientabsturz, obwohl alle das gleiche Build hatten.
Leider war das alles eine sehr zeitaufwendige Angelegenheit, weil die Fehlersuche Stunden gedauert hat. Diese lokale DB war nur zum Zwecke eines nachträglichen Anlegen eines Cronusmandanten in eine andere Datenbank gedacht, die ebenfalls diese Addon-Objekte enthält. Da die Datenimportroutine sich leider nach wie vor sehr mimosenhaft verhält und schon bei einer zusätzlich vorhandenen Tabelle im Zielsystem den Import verweigert, geht das leider nur über eine Zwischendatenbank mit exakt gleichem Schemata. Mit einer fbk wäre das mit drei Mausklicks erledigt gewesen .

Nur die Addonobjekte zu kompilieren (da noch mit mit Synchronize Schema::Later) war nicht ausreichend und führte immer noch zum Clientabsturz

Besteht das Problem nur beim erstmaligen Öffnen der Datenbank, oder jedes Mal nach einem Objektimport?
In letzterem Fall würde das ja heißen, dass NAV-Kunden nach jedem noch so kleinen Update ihres Partners alles neu kompilieren müssten

Oder besteht das Problem nur bei der Kombination aus Sicherung wiederherstellen + Objektimport?

Hallo Kai,

danke für die Warnung. Ich habe hier auch etwas bemerkenswertes: Es kann unerwartete Probleme geben wenn man mit einer etwas älteren Entwicklerlizenz arbeitet oder diese aus Prozessgründen erstmal in der Datenbank gespeichert hat. Vor der offiziellen Verfügbarkeit von NAV2015 konnte man ja bereits mit der Partnerlizenz in die Objekte, brauchte aber die Demolizenz für den RTC. Diese Kombination gibt jetzt ein Problem: Mit der Entwicklungsumgebung kommt man noch ran, der RTC bringt aber verschiedenste lizenzbezogene Fehlermeldungen, von "kein freier User" über "das ist keine kompatible NAV-Lizenzdatei" bis "Server ist ausgelastet". Ich habe mittlerweile eine NAV2015-Partnerlizenz, gefühlt gibt es das Problem erst seit ich diese habe und auf den SQL-Server geladen habe. Die Lizenzdatei aus der DB entfernen löst das Problem nicht. Standard NAV2015 RTM Datenbanken bekomme ich mit dieser Lizenz aber auf und darf designen.

LG Jens

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

In letzterem Fall würde das ja heißen, dass NAV-Kunden nach jedem noch so kleinen Update ihres Partners alles neu kompilieren müssten

Das wird wohl vom Umfang der Änderungen abhängen, bzw. ob und wieviele Tabellen betroffen sind. Hier waren es 51 geänderte Tabellen in 457 Objekten.
Den gesamten obigen Vorgang habe ich analog auch für NAV 2013 R2 Update 12 durchgeführt, ohne Probleme, sogar ohne neukompilieren startete der Client problemlos mit der neuen Datenbank und ich konnte die Cronusdaten auslesen.

Den gesamten obigen Vorgang habe ich analog auch für NAV 2013 R2 Update 12 durchgeführt, ohne Probleme,sogar ohne neukompilieren startete der Client problemlos mit der neuen Datenbank …

Seinerzeit war NAV 2015 ja erst ein paar Tage alt, nun ist mir das Verhalten klar.
Dabei war eben der wesentliche Unterschied, dass NAV 2013 R2 in diesem Moment die Schemasynchronisation ausführt (oder zumindest versucht ), was ab NAV 2015 nun vorher via C/SIDE oder PowerShell bereits erledigt sein muss. Leider produziert NAV 2015 statt einer aussagekräftigen Fehlermeldung in diesem Moment oft nur einen kommentarlosen Clientabsturz.