Alle Objekte kompilieren nach Objektimport?

Ein gesundes neues Jahr zusammen!

Unser NAV Partner hat empfohlen, nach einem Objektimport grundsätzlich alle Objekte in der DB zu kompilieren.
Das kenne ich so von meiner vorherigen Arbeitsstelle (dort war allerdings NAV2009 mit RTC im Einsatz) nicht.
Da haben wir fast nie die Objekte kompiliert, alle schon gar nicht.

Ist das bei NAV2016 tatsächlich immer ratsam, bzw. hängt dies vom zu importierenden Objekttyp ab?

Viele Grüße
Jörg

Hallo,

grundsätzlich ist das nicht falsch, aber gefährlich.

Wenn sichergestellt ist, dass sich vor dem Import alle Objekte compilieren ließen, dann sollte das hinterher genauso sein. Es wird aber dazu führen, dass du vor dem Import und dem compilieren alle Benutzer raus schmeißt, und hinterher die Dienste neu startest.
Das ist nicht immer nötig, z.B. i.d.R nicht bei Berichten.

Bei allem anderen meckert das System wesentlich häufiger "Ein anderer Anwender hat die Definition der Tabelle XX geändert" als in früheren Versionen.

Gruß Fiddi

Es wird aber dazu führen, dass du vor dem Import und dem compilieren alle Benutzer raus schmeißt, und hinterher die Dienste neu startest.

warum sollte er die Dienste neustarten?

Es wird ab NAV 2016 beim Start des Dienstes sowieso alles kompiliert (siehe hier), sofern man das nicht abschaltet.
Wenn die Objekte nicht Referenzen auf Hunderte andere in der Datenbank haben, halte ich das für überflüssig. Anders sieht es bei Importen großer Objektpakete aus. Da sollte man zumindest die Paketobjekte selber neu kompilieren.

Super - danke für die Infos!

Ich kann nur aus meiner Erfahrung mit NAV 5.0 und NAV 2017 sprechen.
Unter NAV 5.0 war es nie erforderlich, nach einem FOB-Import die Objekte zu kompilieren.
Seit NAV 2017 müssen wir immer nach dem Import die importierten Objekte kompilieren, da es ansonsten zu Problemen bei den Objekt Metadaten kommt ("Die Metadaten für Objekte xyz sind nicht synchron.").
Wenn in dem Objektpaket auch eine MenuSuite (z. B. 1090) enthalten war, müssen auch alle MenuSuites kompliert werden, da es ansonsten zu einem Durcheinander kommen kann.

Es ist aber nicht erforderlich, nach einem Update immer alle Objekte zu kompilieren, sondern nur die, die gerade importiert wurden. (Mit der Besonderheit bei den MenuSuites)

da es ansonsten zu Problemen bei den Objekt Metadaten kommt ("Die Metadaten für Objekte xyz sind nicht synchron.").

Ggf. reicht dazu auch diese Funktion.

da es ansonsten zu Problemen bei den Objekt Metadaten kommt ("Die Metadaten für Objekte xyz sind nicht synchron.").

Ggf. reicht dazu auch diese Funktion.

Danke für den Hinweis.
Das ist bedeutend einfacher, als alle gerade importierten Objekte herauszufinden.

Wenn in dem Objektpaket auch eine MenuSuite (z. B. 1090) enthalten war, müssen auch alle MenuSuites kompliert werden, da es ansonsten zu einem Durcheinander kommen kann.

Zusatz: Mit der Lizenz, die für den Betrieb der Instanz gedacht ist.

Ggf. reicht dazu auch diese Funktion.

Je nach Umgebung reicht das auch nicht aus. Wenn man mehrere NSTs auf eine DB hat, muss man ggf. zusätzlich noch einen Sync bzw. Neustart der NSTs, die nicht die Aktion aus dem Dev Client ausgeführt haben, durchführen.

Generell kann ich sagen, das Thema war noch nie einfach, und die 3-Schichten-Umgebung hat es nicht einfacher gemacht. Aus meiner Sicht gibt es kein Ja oder Nein bzgl. Kompilieren aller Objekte und Neustarten. Es hängt davon ab, was man macht und welche Konsequenzen darauf folgen und inwieweit man diese in Kauf nehmen kann. Prinzipiell bin ich kein Freund davon alles zu kompilieren, auch weil man sich damit wie andere schon erwähnt haben, andere Problem einfangen kann. Es gibt aber Situationen, in denen es besser ist, das zu tun, um sicherzugehen, dass man keine Querbezüge auf die geänderten Objekte zerstört hat. Das sollte allerdings eigentlich der Partner vorab herausfinden meiner Meinung nach.

Dann sind wie gesagt MenuSuites gesondert zu behandeln. Codeunits kann man eigentlich einfach so abändern, allerdings gibt es dann auch wieder Single Instance Codeunits. Tabellenänderungen sind strukturelle Änderungen am Datenmodell, auch hier gilt besondere Aufmerksamkeit. Ein Force Sync löscht dir unter Umständen Daten weg, wenn du nicht aufpasst (das ging in den guten, alten Zeiten gar nicht vom System aus).

Alles in allem kann man sagen, dass die Verantwortung der Techniker und Admins deutlich gestiegen ist akkurat zu arbeiten und genau zu wissen, was man gerade macht und entsprechende Sicherheitsnetze einzuziehen.

Ein Force Sync löscht dir unter Umständen Daten weg, wenn du nicht aufpasst (das ging in den guten, alten Zeiten gar nicht vom System aus).

guten alten Zeit? in der guten alten Zeit hatten wir auch im DevClient keine Farben und an IntelliSense war gar nicht zu denken - aber ich will hier keine Diskussion der Vor-/Nachteile von "Alt" vs "Neu" anfangen.
Das eventuelle Löschen bei Force hat auch sein Vorteile :)

Alles in allem kann man sagen, dass die Verantwortung der Techniker und Admins deutlich gestiegen ist akkurat zu arbeiten und genau zu wissen, was man gerade macht und entsprechende Sicherheitsnetze einzuziehen.

korrekt

Alles gut. War jetzt kein Nostalgie-Post von mir, sondern mehr mit einem Augenzwinkern zu verstehen.