Upgradeprozess mit ISV Lösungen

Hallo zusammen,

ich versuche mich an einem Upgrade in einer Testumgebung von NAV 2013 auf NAV 2017. Es gibt zwei ISV Lösungen, die ebenfalls aktualisiert werden müssen. Wie geht man hier bei einem Upgrade am besten vor? Es ist mein erstes Upgrade und ich stelle mir ein paar Fragen (ich nutze hier die Begrifflichkeiten der Microsoft Guideline für den Merge):

- Soll ich die ISV-Lösungen bereits in die TARGET-Version für den Merge integrieren oder gegen die 2017 "Vanilla" mergen und anschließend erst die ISV Lösungen (nacheinander?) reinmergen?
- Wird die gesamte Applikation inkl. der ISV Lösungen gemerged oder merged man am besten zuerst nur die Standard-Objekte aus 2013 MODIFIED gegen 2017 TARGET und installiert dann anschließend jeweils die aktuellen FOBs der ISVs?

Ich würde intuitiv wie folgt vorgehen:

- Automatischer Merge aller Standard- und Kundenobjekte (ohne ISV Objekte) mit Powershell. Als TARGET nehme ich NAV 2017 ohne ISV Lösungen
- Aufbau einer leeren 2017 Datenbank, importieren der FOBs der ISV Lösungen, anschließend Import des Merge Ergebnisses
- Erneuter, manueller Merge der Standard-Objekte, in denen die ISV-Lösungen Anpassungen vorgenommen haben, um die Änderungen zwischen den ISV-Versionen nachzuziehen

Würde das so funktionieren? Ich habe die Vermutung, dass ich mir das Leben zu schwer mache und es einen einfacheren Weg gibt. Gibt es ein "Best Practice"?

Vielen Dank vorab!

Meiner Meinung nach, auch unterstützt durch ein erfolgreiches Upgrade von 2015 auf 2017 vor einem Monat, sollten SOURCE, TARGET und MODIFIED die Zusatzmodule und Lösungen bereits enthalten. Ansonsten hast du ja als erste "Differenz" schonmal alles was zuviel ist oder zu wenig.

Ablauf bei uns war ganz grob:

• Vorbereitung der Objektdatenbanken (ohne Daten) SOURCE (NAV Standard inkl. ISV), TARGET (NAV Standard inkl. ISV)
• MODIFIED bereitstellen aus aktueller Datenbank (nur Objekte)
• Automatischer Merge
• Manueller Merge (bei Konflikten)

Alles andere macht dir das Leben unnötig schwer, wie du selbst vermutet hast

Danke für die schnelle Hilfe! Auf die Idee, die ISV Lösung bereits in die ORIGINAL zu integrieren, bin ich gar nicht gekommen. Macht aber durchaus Sinn.
Das Ergebnis sieht auf den ersten Blick auch schon sehr gut aus. Es gibt ein paar Konflikte, aber lange nicht mehr so viele wie bei meinen vorherigen Versuchen.

Hallo,

ich halte persönlich nichts vom automatischen Merge mit den MS-Mergetools, weil man nicht mehr mit bekommt, was sich geändert hat, und evtl. bei eigenen Anpassungen berücksichtigt werden kann oder muss.

Das ist aber nur eine Sache. Der automatische Merge mit den NAV-Tools birgt aber auch den Nachteil, das er mehrere ISV Lösungen zwar textlich korrekt mergt, aber die Aufrufreihenfolge u.U. aber nicht berücksichtigt wenn sich Codeanpassungen zweier ISV-Lösungen überschneiden, was fatale Folgen haben kann.
Das NAV- Mergetool versucht auch "intelligent" zu sein, und versucht anhand von IDs und Variablennamen Controls zuzuordnen, das kann schon mal schief gehen. Besonders dann wenn es Überschneidungen bei Variablennamen den ISV- Lösungen gibt.

Es gibt diverse visuelle Mergetools, die einen Diff3- Merge mit den Textexporten durchführen können können. Bei denen bekommt man mit, wenn etwas gemergt wird, auch wenn sie es "theoretisch" automatisch hinbekommen. Man halt also die Möglichkeit sich anzuschauen, was geändert wurde, muss es aber nicht.

Grundsätzlich benötigt man für einen Diff3 Merge eine eigene Version eine Version die man erreichen möchte, und einen gemeinsamen Vorfahren beider Versionen, die möglichst nahe an beide Versionen herankommt.

Wenn du noch die Ausgangsversion mit beiden ISV-Lösungen für eure NAV 2013- Datenbank hast, dann könnte das dein Vorfahre für den Merge sein.
Was du dann noch benötigst, ist die NAV2017- Version mit beiden ISV-Lösungen. Die musst dir dann auch zusammenstellen aus der ersten ISV-Lösung, dem gemeinsamen Vorfahren (auf den Build der einzelnen Versionen achten) und der zweiten ISV- Lösung.
Der endgültige Merge findet dann zwischen deiner Version der NAV2013- Basis Version und der NAV2017-Lösung statt.

Hast du die Basis NAV2013- Version nicht. kannst du versuchen die ISV- Lösungen einzeln zu mergen mit deiner Version einer nakten NAV2013 und jeweils der ISV-Lösung.

Gruß Fiddi

Danke für deine Ausführungen Fiddi, aber so ich verstehe nicht ganz, was du mit dem "gemeinsamen Vorfahren" meinst. Grundsätzlich benötige ich doch dieselben Versionen wie beim automatischen Merge, nur dass ich eben den Merge manuell durchführe, oder nicht?

Für den automatischen Merge habe ich mir 2013 inkl. ISV als Original und 2017 inkl. ISVs als Target aufgebaut. Die von beiden ISVs angepassten Standard-Objekte habe ich jeweils manuell gemerged (war nur eine handvoll). Danach habe ich den Merge per Powershell mit der 2013 "Live" Datenbank als Modified durchgeführt. Wie hätte ich bei dem manuellen Merge vorgehen müssen? Ich stehe dem automatischen Merge auch eher skeptisch gegenüber (da ich schon einige Merges mit einem anderem ERP-System durchgeführt habe und die Schwierigkeiten und Probleme beim mergen durchaus kenne), daher interessiert mich auch der manuelle Weg.

ich halte persönlich nichts vom automatischen Merge mit den MS-Mergetools, weil man nicht mehr mit bekommt, was sich geändert hat,

Während des Mergens sicherlich nicht, aber bei der Nachkontrolle sieht man ja alles, was passiert ist. Ich merge alle Cumulative Updates mit diesen Tools und vergleiche jeweils das aktuelle Mergeergebnis zum Objektpaket des Vormonats d.h. dem letzten Mergeergebnis. So passieren unter dem Strich wesentlich weniger Fehler, als wenn ich das alles manuell machen würde.
Bei sehr stark angepassten Objekten in größeren Upgrades muss man diese eventuell manuell komplett nachmergen, aber die kann man meist an ein bis zwei Händen abzählen.

Hallo,

ich meinte nicht, mich von einem Mergetool beim Mergen Vorschläge für das Ergebnis machen zu lassen. Aber das Mergeergebnis einfach so hinzunehmen, bzw. gar nicht zu wissen, das etwas geändert wurde, finde ich keine gute Idee.

Ich persönlich setzte ein Mergetool ein, das mit 4 Versionen arbeitet (Kundenversion,Vorfahre, Ziel, Ziel-Kundenversion) (Beyond oder Ellié). Die beiden erledigen richtig eingerichtet 90% und mehr der Mergearbeit automatisch, aber nicht ohne mir anzuzeigen, dass etwas getan wurde. Ich kann das ohne zu prüfen übernehmen, oder nochmal nachschauen und ändern. Was nicht automatisch funktioniert muss man sich dann genauer anschauen, es betrifft dann aber eher selten alle Änderungen, sondern nur ein Teil eine Objektes.

Gruß Fiddi

Auch wenn das vielleicht etwas offtopic ist, aber mit Beyond meinst du "Beyond and Compare"? Wie kann man damit automatisch mergen? Das ist doch nachher wieder ein manueller Textmerge oder hast du dort ein anderes Vorgehen. Kannst du evtl. kurz beschreiben, wie du den merge mit einem solchen Tool zu 90% automatisch durchführst?

Auch wenn das vielleicht etwas offtopic ist, aber mit Beyond meinst du "Beyond and Compare"? Wie kann man damit automatisch mergen? Das ist doch nachher wieder ein manueller Textmerge oder hast du dort ein anderes Vorgehen. Kannst du evtl. kurz beschreiben, wie du den merge mit einem solchen Tool zu 90% automatisch durchführst?

Hab mir gerade mal die Demo-Version von Beyond-Compare heruntergeladen. die Professional-Version beherrscht wie Elliè (was ich selbst normalerweise einsetze) einen DIFF3 mit Ausgabe in einen vierten Ordner.

Wenn man jetzt in Beyond einen Ordner-Vergleich mit 3 Ordnern durchführt in denen die einzelnen Objekte als Textdateien vorliegen, ist meine Vorgehenweise folgende:

• Es werden zunächst alle Objekte gefiltert, die in allen drei Versionen gleich sind. Die werden je nach Zieldatenbank entweder ignoriert oder in den Ausgabeordner kopiert.
• Alle Objekte die in Kunden-DB (links) und und Vorfahre (Mitte) aber in der Zielversion (rechts) anders sind, können (theoretisch) in den Ausgabeordner kopiert werden, da hier keine Anpassungen zu berücksichtigen sind, sondern nur neues da ist.
• Alle Objekte wo nur die Kunden-DB geändert ist, aber nicht Vorfahr und Ziel, können (theoretisch) entweder ignoriert oder in den Ausgabe-Ordner kopiert werden, da hier keine Anpassungen von NAV- Seite vorhanden sind, können die Kundenänderungen übernommen werden.
• Damit sind, je nach Delta zwischen den Versionen (beim normalen monatlichen CU-Merge weit über 90 %), der größte Teil der Objekte erledigt
• Jetzt kommen die Objekte bei denen sich sowohl Links und Mitte als auch Mitte und Rechts unterscheiden. Hier schafft es das Programm oft (Wenn die Datums- und Versionsangaben im Objektkopf nicht währen, auch noch mehr) einen automatischen Vorschlag für das Ergebnis zu machen, wenn sich die Änderungen in den Objekten nicht überschneiden. Das kann man so akzeptieren, oder man schaut noch mal drüber, bevor man es in den Ausgabeordner überträgt.
• Der letzte Schritt ist dann der Handmerge, bei Objekten in denen sich die Änderungen in allen Versionen überschneiden. Hier muss eine Person wirklich manuell eingreifen und entscheiden was von wo nach wo kopiert oder evtl. sogar angepasst werden muss. Das ist bei uns beim CU-Merge ca. 10 bis 20 Objekte von 6000.

Diese Vorgehensweise ist eigentlich die gleiche wie sie das MS- Powershell- Tool auch durchführt, man hat als Anwender aber mit einem der Tools jederzeit die volle Kontrolle über den Prozess und man muss nur ein Tool verwenden, statt zwei (MS-Merge und anderes Mergetool für die Konflikte)

Ein weiterer wichtiger Grund das mit einem visuellen Tool zu machen, ist für mich auch die Möglichkeit Änderungen im NAV mit zu bekommen.
Ein aktuelles Beispiel ist z.B. Verwendung neuer Copy-Funktionen in den Postentabellen und Journalen in NAV2017. Der automatische Merge hätte die bei mir klaglos gemergt. Ob meine Anpassungen, die zusätzliche Felder zwischen den Tabellen übertragen, danach noch funktioniert hätten, wage ich allerdings zu bezweifeln. Und solche Fehler merkt man meistens nicht sofort

Gruß Fiddi

Ein weiterer wichtiger Grund das mit einem visuellen Tool zu machen, ist für mich auch die Möglichkeit Änderungen im NAV mit zu bekommen.
Ein aktuelles Beispiel ist z.B. Verwendung neuer Copy-Funktionen in den Postentabellen und Journalen in NAV2017. Der automatische Merge hätte die bei mir klaglos gemergt. Ob meine Anpassungen, die zusätzliche Felder zwischen den Tabellen übertragen, danach noch funktioniert hätten, wage ich allerdings zu bezweifeln. Und solche Fehler merkt man meistens nicht sofort

In diesem Fall generiert der automatische Merge einen Konflikt, da das zusätzliche Kopieren von neuen Feldern als Änderung erkannt wurde. Das hatte ich bei meinem aktuellen Beispiel auch und es wurde erkannt.

Aber mal noch eine grundsätzliche Frage von mir: Geht ihr bei einem CU genauso wie bei einem Upgrade vor, was den Objektmerge angeht? Was spricht dagegen, nur die in der Quelldatenbank geänderten Objekte mit den Objekten aus dem CU zu mergen und alle anderen Objekte über die FOB einzuspielen? Ist der Aufbau der drei Objektstände für ein CU nicht zuviel Aufwand?

Was spricht dagegen, nur die in der Quelldatenbank geänderten Objekte mit den Objekten aus dem CU zu mergen und alle anderen Objekte über die FOB einzuspielen?

Man kann die geänderten Objekte nicht zweifelsfrei erkennen, ohne den Inhalt zu prüfen. Auf den "Geändert"-Haken ist kein Verlass, den kann man jederzeit (versehentlich) zurücksetzen, und auf den Inhalt auf die Versionsliste auch nicht immer.

Nur bei klar definierten Objektbereichen (Add-on-Objekte mergen, andere nur per Fob-Import mit der neuen Version ersetzen) kann man gefahrlos anders vorgehen.

Was spricht dagegen, nur die in der Quelldatenbank geänderten Objekte mit den Objekten aus dem CU zu mergen und alle anderen Objekte über die FOB einzuspielen?

Das Modified-FLAG halte ich für eines der überflüssigsten Informationen im NAV, es abzufragen ist der größte SCH... .

Objekte können auch indirekt geändert werden (ohne das das Modified-Flag geändert wurde), weil sich z.B. Feldnamen ändern, oder noch schlimmer Objekte verschoben oder sogar ausgetauscht werden ( 1 -> 2 und 2->1) das gibt beim FOB-Import Chaos.

Außerdem kann es passieren, das jemand CU- gemergte Objekte ohne Änderungsflag eingespielt hat, weil es schnell gehen musste.
Daher immer den kompletten Objektstand mergen, man muss ja nur das übernehmen was sich geändert hat. Die 2 Minuten, die der Export bzw. der Merge länger dauert wiegen nicht die möglichen Fehlerquellen auf.

In diesem Fall generiert der automatische Merge einen Konflikt, da das zusätzliche Kopieren von neuen Feldern als Änderung erkannt wurde.

Das kann so sein, muss es aber nicht.

Besonders in dem o.g. Fall mit den ausgetauschten Objekten kann es richtig schief gehen.

Gruß Fiddi

Ok, also benötige ich bei einem CU eine NAV Standard-DB mit dem aktuellen CU-Level, die Kunden-DB und eine Standard DB mit dem Ziellevel. Daraus würde ich wieder alle Objekte (ohne Addons) exportieren und (wie auch immer) mergen!?

Hallo,

wenn du einmal auf der Schiene mit dem Mergtool bist, benötigst du eigentlich immer nur die Neue Version. Die alte Version ist das (fehlerbereinigte) Ergebnis des letzten Merges. Die Kunden-Version ziehst du dir die aktuelle.

Daher gilt: die Vorbereitungen für das nächste Merge beginnen mit dem aktuellen

Gruß Fiddi

Stimmt, mich interessieren ja nur die Änderungen an der Kunden-DB seit dem letztem CU.
Gibt es dazu (und auch zum Thema Upgrade an sich) eigentlich gute Literatur,Videos, etc. (abseits der bekannten Quellen auf der MSDN und div. Blogs) wo man als Anfänger tiefer einsteigen kann?

wenn du einmal auf der Schiene mit dem Mergtool bist, benötigst du eigentlich immer nur die Neue Version. Die alte Version ist das (fehlerbereinigte) Ergebnis des letzten Merges. Die Kunden-Version ziehst du dir die aktuelle.

Das habe ich jetzt einmal ausprobiert. Das Ergebnis ist allerdings nicht sehr zufriedenstellend. Der automatische Merge hat alle Standard-Objekte, an denen zwischen den beiden CUs keine Änderungen erkannt wurden, durch das Target-Objekt ersetzt. Habe ich etwas falsch gemacht? Als Source und Modified habe ich jeweils die Kundendatenbank auf dem Stand 2017 RTM verwendet, als Target die Demo Datenbank aus 2017 CU7.

Als Source und Modified habe ich jeweils die Kundendatenbank auf dem Stand 2017 RTM verwendet

Wenn das bedeutet, dass ORIGINAL und MODIFIED identisch sind, ist das verkehrt.

Beispiele für Setups

Update Major Release
ORIGINAL: NAV 2016 DE (+ CU xx)
MODIFIED: NAV 2017 DE (+ CU yy)
TARGET: NAV 2016 DE (+ CU xx) + AddOn
RESULT: NAV 2017 DE (+ CU yy) + AddOn

2 AddOns zusammenführen
ORIGINAL: NAV 2017 DE (+ CU xx)
MODIFIED: NAV 2017 DE (+ CU xx) + Addon1
TARGET: NAV 2017 DE (+ CU xx) + Addon2
RESULT: NAV 2017 DE (+ CU xx) + AddOn1 + Addon2

Cumulative Update (hier von CU 08 -> 09)
ORIGINAL: NAV 2017 DE CU 08
MODIFIED: NAV 2017 DE CU 09
TARGET: NAV 2017 DE CU 08 + AddOn
RESULT: NAV 2017 DE CU 09 + AddOn

AddOn in andere Länderversion übertragen (vor dem Merge alle Sprachlayer bis auf ENU entfernen und am Ende wieder zufügen)
ORIGINAL: NAV 2017 DE (+ CU xx)
MODIFIED: NAV 2017 GB (+ CU xx)
TARGET: NAV 2017 DE (+ CU xx) + AddOn
RESULT: NAV 2017 GB (+ CU xx) + AddOn

Grundsätzlich: TARGET bedeutet nicht das Endziel, sondern das TARGET wird mit ORIGINAL und MODIFIED "beschossen" und es entsteht dabei ein RESULT.

Danke, das hilft mir, das Tool besser zu verstehen.

Cumulative Update (hier von CU 08 -> 09)
ORIGINAL: NAV 2017 DE CU 08
MODIFIED: NAV 2017 DE CU 09
TARGET: NAV 2017 DE CU 08 + AddOn
RESULT: NAV 2017 DE CU 09 + AddOn

Könnte man hierbei nicht die AddOns außen vor lassen, da ein CU nur die Standard-Objekte verändert?

Könnte man hierbei nicht die AddOns außen vor lassen, da ein CU nur die Standard-Objekte verändert?

Sinngemäß sieht das so aus:
Das Addonpaket besteht z.B. aus 400 Objekten (150 Standardobjekte wurden modifiziert bis ID 49999 + 250 eigene im AddOn-Nummernbereich )

Cumulative Update (hier von CU 08 -> 09)
ORIGINAL: NAV 2017 DE CU 08 -> die 150 Standardobjekte, welche das AddOn berührt
MODIFIED: NAV 2017 DE CU 09 -> die gleichen 150 Standardobjekte, welche das AddOn berührt
TARGET: NAV 2017 DE CU 08 + AddOn (alle 400 Objekte, die für das AddOn notwendig sind)
RESULT: NAV 2017 DE CU 09 + AddOn (alle 400 Objekte die für das AddOn notwendig sind. Diesen Rohmerge aus RESULT einspielen in die NAV 2017 DE CU 09-Datenbank)

Natürlich kann man auch komplette Objektexporte in ORIGINAL, MODIFIED und TARGET packen, aber das ist nur sinnloser Datenmüll.

Exportmöglichkeiten bei gleichbleibender Objektliste mittels Objektindex
viewtopic.php?f=17&t=25242
viewtopic.php?f=17&t=28242
viewtopic.php?f=17&t=28773
Export via Fobpaket
viewtopic.php?f=17&t=28259#p122051

Ich verstehe nicht, warum ich das AddOn mitführen muss. Daran ändert sich durch das CU doch nichts. Und was ist mit den weiteren Kundenanpassungen, wenn ich nur die Addon-Standardobjekte als ORIGINAL und MODIFIED auswähle? Die muss ich doch auch berücksichtigen.

Intuitiv wäre ich folgenden Weg gegangen:

TARGET: NAV 2017 DE CU 08 (Nur Standardobjekte, ohne Objekte aus dem AddOn Bereich)
MODIFIED: NAV 2017 DE CU 09 (Nur Standardobjekte, ohne Objekte aus dem AddOn Bereich)
ORIGINAL: NAV 2017 DE CU08 (Nur Standardobjekte, ohne Objekte aus dem AddOn Bereich)

Würde ich den Merge zu Fuß durchführen, müsste ich mir doch auch nur die Standardobjekte ansehen, die durch das CU verändert worden sind.

Ich verstehe nicht, warum ich das AddOn mitführen muss. Daran ändert sich durch das CU doch nichts. Und was ist mit den weiteren Kundenanpassungen, wenn ich nur die Addon-Standardobjekte als ORIGINAL und MODIFIED auswähle? Die muss ich doch auch berücksichtigen.

Natürlich kann man Addon-Objekte außerhalb vom Standardbereich auch als Fob in die Zieldatenbank importieren, das bedeutet aber zwei Importvorgänge in die Zieldatenbank, der obige Weg nur einen, und damit eine Fehlerquelle weniger.
Wenn das Addon Funktionen aus dem Standard nutzt, die sich ggf. im Cumulative Update verändert haben, muss allerdings auch das AddOn angepasst werden. Das merkt man aber bei beiden Methoden erst beim Komplilieren.

Das war ein Beispiel für ein AddOn-Merge, wie es Partner auf Basis der von MS gelieferten Datenbanken bereitstellen, also ohne Kundenanpassungen.

Also geht man auch bei einem CU den Weg über die Standard-Zieldatenbank und importiert da zunächst das Merge-Ergebnis als TXT, erstellt eine FOB aus allen Objekten und importiert diese dann in die Kundendatenbank? Hierbei müsste ich das AddOn ja ohnehin vorher per FOB in die Standard-Zieldatenbank importieren, da ich die TXTs nicht importieren kann, wenn Felder mit einer ID aus dem AddOn Bereich enthalten sind. Warum sollte man das Merge-Ergebnis bei einem CU nicht direkt in die Kundendatenbank importieren? Aus Sicht eines ISV ist das Vorgehen logisch, da man ja eine FOB zum Auslieferen/Bereitstellen benötigt, aber ich habe eine andere Sichtweise.

Hierbei müsste ich das AddOn ja ohnehin vorher per FOB in die Standard-Zieldatenbank importieren, da ich die TXTs nicht importieren kann, wenn Felder mit einer ID aus dem AddOn Bereich enthalten sind.

Wenn die AddOns zertifiziert sind, haben die eigene Nummernbereiche, wenn nicht, muss man die IDs durchgehend ändern falls Konflikte auftauchen. Bei zertifizierten AddOns kann es bei der Zusammenführung auch Fehlnamenkonflikte geben, wenn beide in einer Tabelle den selben Feldnamen benutzen. Das kann auch beim Überführen in andere Länderversionen wegen dort örtlichen Feldern im Standard passieren. Das ist immer manuelle Nacharbeit, egal wie man mergt. Das Mergecmdlet meldet da auch leider keine Konflikte, erst der Import.

Warum sollte man das Merge-Ergebnis bei einem CU nicht direkt in die Kundendatenbank importieren?

Das geht auch.
Bedeutet praktisch: Zur Sicherheit dann aber alle Objekte exportieren, das Thema dass man die geänderten meist nicht eindeutig erkennen kann, hatten wir ja schon. Theoretisch: Wenn man den Objektindex um die Kundenobjekte erweitert.

Je nach Komplexität ist es aber durchaus von Vorteil, erst einmal sicherzustellen, dass beide AddOns auf dem aktuellen Standard zusammen funktionieren. Dann weiß man zumindest, woran es nicht liegt, wenn die Zusammenführung mit den Kundenobjekten dann neue Fehler erzeugt, die bisher nicht vorhanden waren. Wenn es dann Probleme gibt, kann man das Buchungsverhalten von Standard + beiden AddOns ohne Kundenanpassungen im Cronusmandaten prüfen und dann das besser einkreisen.

Außerdem wäre das die Kontrollvorlage für den nächsten Upgradevorgang vor dem Zufügen der Kundenanpassungen. Wenn man bei einem komplexeren Upgrade einen Mergefahrplan anhand relativ einfachen kleinen klar definierter Teilschritten hat, muss man beim nächsten Upgradevorgang an allen relevanten Stellen nur die jeweils aktuellen Objektpakete verwenden. Diese Systematik zahlt sich langfristig aus.

Wenn die AddOns zerifziert sind, haben die eigene Nummernbereiche, wenn nicht muss man die IDs durchgehend ändern falls Konflikte auftauchen. Bei zertifizierten AddOns kann es bei der Zusammenführung auch Fehlnamenkonflikte geben, wenn beide in einer Tabelle den selben Feldnamen benutzen. Das kann auch beim Überführen in andere Länderversionen wegen dort örtlichen Feldern im Standard passieren. Das ist immer manuelle Nacharbeit, egal wie man mergt. Das Mergecmdlet meldet da auch leider keine Konflikte, erst der Import.

Hierbei meinte ich eher die Lizenzproblematik. Neue Felder mit IDs aus zertifizierten Bereichen lassen sich ja nur per FOB erzeugen. Der ISV hat das Problem mit seiner Lizenz natürlich nicht.

Bedeutet Praktisch: Zur Sicherheit dann aber alle Objekte exportieren, das Thema dass man die geänderten meist nicht eindeutig erkennen kann, hatten wir ja schon. Theoretisch: Wenn den Objektindex um die Kundenobjekte erweitert.

Also wäre das dann dieser Weg?

TARGET: NAV 2017 DE CU 08 (Aktuelle Kundendatenbank, ALLE Standardobjekte, ohne Objekte aus dem AddOn Bereich)
MODIFIED: NAV 2017 DE CU 09 (MS Demo Datenbank, ALLE Standardobjekte, ohne Objekte aus dem AddOn Bereich)
ORIGINAL: NAV 2017 DE CU08 (Aktuelle Kundendatenbank, ALLE Standardobjekte, ohne Objekte aus dem AddOn Bereich)

Je nach Komplexität ist es aber durchaus von Vorteil, erst einmal sicherzustellen, dass beide AddOns auf dem aktuellen Standard zusammen funktionieren. Dann weiß man zumindest, woran es nicht liegt, wenn die Zusammenführung mit den Kundenobjekten dann neue Fehler erzeugt, die bisher nicht vorhanden waren. Wenn es dann Probleme gibt, kann man das Buchungsverhalten von Standard + beiden AddOns ohne Kundenanpassungen im Cronusmandaten prüfen und dann das besser einkreisen.

Das stimmt. Die Frage ist nur, ob sich die Prozesse überhaupt ohne die anderen Anpassungen testen lassen (wenn z.B. kundenindividuelle Tabellenfelder fehlen, die beim Buchen gebraucht werden).

Also wäre das dann dieser Weg?

TARGET: NAV 2017 DE CU 08 (Aktuelle Kundendatenbank, ALLE Standardobjekte, ohne Objekte aus dem AddOn Bereich)
MODIFIED: NAV 2017 DE CU 09 (MS Demo Datenbank, ALLE Standardobjekte, ohne Objekte aus dem AddOn Bereich)
ORIGINAL: NAV 2017 DE CU08 (Aktuelle Kundendatenbank, ALLE Standardobjekte, ohne Objekte aus dem AddOn Bereich)

Wenn ich dich richtig verstehe, und die Kundendatenbank hier von CU08 auf CU09 soll, läuft das so wie schon für Cumulative Updates beschrieben.
ORIGINAL : NAV 2017 DE CU08 (MS Demo Datenbank)
MODIFIED: NAV 2017 DE CU09 (MS Demo Datenbank)
TARGET: NAV 2017 DE CU 08 (Aktuelle Kundendatenbank)