Upgrade von 2.60 auf NAV CH 4.0 SP2

Hallo zusammen

gerne würden wir einen Upgrade von NF 2.60 auf NAV 2009 vornehmen. Wie hier gelesen macht man dabei zuerst einen Zwischenschritt und hebt zuerst alles auf 4.0 an. Dort bleibe ich nun hängen.
Habe alles soweit vorbereitet aber beim Versuch W1CH_Upgrade260400SP2.1.fob zu importieren bricht der dies ab mit der Meldung : "Der folgende Feldname kann nur einmal in der Tabelle vewendet werden: Feldname: Status, Tablle: Verkaufskopf".

Habe ich evtl. eine falsche Fob? oder hat jemand eine Idee?

Besten Dank :)

Hallo,

Mit Version 3 sind in NAV nicht mehr die Feld-IDs in den Tabellen bestimmend, welches Feld adressiert wird, sondern der Feldname, das kann mit der neuen Version zu Problemen führen.
Genauso tritt das Problem auf, wenn du die die neuen Objekte mit Merge einliest. Es muss immer mit "Replace all" eingelesen werden.

Gruß, Fiddi

Hallo Fiddi

mmh "Replace all" geht nicht, da er da sonst gerne die Tabellen leer hat...
oder verstehe ich den Schritt 3 vom Upgrade Quick Guide falsch? Open the old costumized data using the new 4.0 client -> Restore the backup of the old customized database resp. convert the old database. Denke schon dass ich hier dies mit den Daten einlesen sollte?

Gruss Alex

Das habe ich mir schon gedacht.

bevor du das Update fahren kannst, musst du dir erst einmal eine neue Version bauen, in der eure Anpassungen wieder enthalten sind, sofern gewünscht. Für alles andere musst du Step1 des Updates so anpassen, das die Felder, die nicht mehr benötigt werden, gelöscht werden (Boolean = false,Decimal/integer=0,....), bzw. Felder deren Daten anders weiter verwendet werden sollen müssen in Hilfstabellen in Sicherheit gebracht werden, damit die Daten in Step 2 wieder in die neuen Felder übernommen werden können.

Es ist also keineswegs damit getan, für ein Update die Upgrade- Toolkits einzuspielen und laufen zu lassen. Die Upgrade- Objekte müssen je nach Größe der Kundenanpassung u.U. erheblich angepasst werden, damit ein Update korrekt laufen kann. Außerdem muss eine neue Version (4 bzw. 2009)erstellt werden (für 4 nur die Tabellen, für 2009 alle Objekte), damit man später annähernd so weiter arbeiten kann wie vorher. Das Upgrade- Toolkit übernimmt diese Anpassungen nicht.

Gruß, Fiddi

Sorry Fiddi ich nochmals

Ich stehe wohl ein klein wenig auf dem Schlauch...
Ich habe die Objekte alle mit dem MergeTool soweit auf den neuen Stand gebracht und aus Navision Development Toolkit als Textdatei in eine neue Datenbank (mandandtNeu.fdb) gebracht soweit so gut.
Muss ich denn die W1CH_Upgrade260400SP2.1.fob in diese DB einlesen? oder wie im Guide beschrieben in eine aus 2.6 neu konvertierete DB (convMandant.fdb)?

Gruss Alex

Also der Update läuft folgendermaßen:


1. aktuelle DB 2.6
2. Upgradetoolkit Step1 für 2.6 nach 4.0 einspielen (angepasst an die Kunden-DB 2.6 mit Sicherung der auch in 2009 benötigten nicht- Standardfelder, und löschen der nicht mehr benötigten bzw. gesicherten Felder)
3. Ausführen Step1 2.6->4
4. Einspielen neue Version 4.0 mit gemergten Feldern aus 2.6 oder auch nicht, wenn man die Felder in Step1 in einer Sicherungstabelle gesichert hat (nur Tabellen, andere Objekte sind nicht nötig, wir wollen ja nach 2009)
5. Einspielen Step2 2.6->4
6. Ausführen Step2 2.6->4
7. Einspielen Step1 4->2009
8. Ausführen Step1 4->2009
9. Einspielen endgültiger Objektstand (alle Obj) 2009
10. Einspielen Step2 4->2009
11. Ausführen Step2 4->2009
12. Einrichtungsdaten 2009 ergänzen (sofern nicht im UGT programmiert)
13. NAV Anwendung starten und buchen, und hoffentlich freuen, wenn alles funktioniert

WICHTIG:
1. je nach alter Client- Version musst du die zu konvertierende DB zunächst auf die technische Umgebung 2009 bringen. dazu sind u.U. mehrere Schritte notewendig, da NAV2009 nicht mehr jede alte 2er FBK einlsen kann. (also 2.6er .fbk mit technisch 4er-Client in eine neue DB einlesen, erst danach diese DB mit einem 2009er-Client öffenen. Soll bei der Gelegenheit auch von native auf SQL umgestellt werden, muss vor dem Schritt des einlesens in SQL die native DB noch auf Feldinhaltsfehler geprüft werden.

2. Das Einspielen der Objekte immer mit "Replace all". Die Fobs bzw. Upgrade-Steps müssen dazu aufeinander abgestimmt sein.

3. sämtliche Objekte müssen so angepasst werden, das beim durchlaufen der Schritte keine in 2009 benötigte Daten verloren gehen, bzw. im Schritt 11 wieder dorthin kommen, wo sie in 2009 sein sollen. Wie die Objekte angepasst werden müssen hängt u.a. auch von der Laufzeit des Updates, bzw. dem zu bewältigenden Datenvolumen ab.

Welches Merge- Tool hast du denn eingesetzt? Der Unterschied zwischen 2.6 und 2009 ist so gravierend, das du da mit einem womöglich automatischen Merge nicht sehr weit kommt.

Gruß, Fiddi

ich habe das Navision Development Toolkit benutzt, da wir sehr wenig Änderungen vorgenommen haben in der alten DB.
So sind zB. einige Felder statt Text 30 auf Text 40 erweitert worden und noch 2 eigene Tabellen hinzugefügt worden, aus diesem Grund habe ich dieses Toolkit genommen.
Welches würdest du empfehlen?

Ich bin schon mal froh wenn das ganze Ding überhaupt mal im 4.0 drin ist .

noch eine Frage zu deiner Antwort beim 2. Punkt, machst du dies mit einer an den Customer angepasste DB (also Original Customer) welche du in der Version NAV 4.0 öffnest/resp. konvertierst ?

muss ich eigentlich die ObjectsNOID_cust.txt ausser im Mergetool auch in die DB zurücklesen, könnte da noch etwas schiefgelaufen sein?

Gruss Alex

Also, ich würde die Datenbank, die konvertiert wird immer aus einer .fbk aufbauen. Des hat den Vorteil, das die alte DB funktionsfähig bleibt, und falls etwas schief geht, man mit dem alten System weiter arbeiten kann. Außerdem bringen die neu aufgebauten Schlüssel u. Tabellen einen geschwindigkeitsvorteil beim Update. (ist deine alte DB allerdings sehr groß, muss man sich überlegen, evtl. vor dem eigentlichen Update ein technisches Update durchzuführen, und das Update der Anwendung auf einem späteren Zeitpunkt verlegen)
Ich bin mir nicht sicher ab welcher 2er Version man ohne .fbk in eine 4er- DB konvertieren kann. Das musst du probieren. Kannst du die 2er- DB mit dem 4er- Client öffnen, ist alles O.K., sonst hilft nur der WEG über die .fbk. Auf jedem Fall das Update auf einer Kopie durchführen.

deine Frage zu Punkt 2 habe ich nicht ganz verstanden. ich versuche jetzt trotzdem eine Antwort: Wenn der Kunde angepasste Felder hat, musst du auch das UGT sowie alle Objekte bis zu endgültigen Version 2009 die davon betroffen sind daran anpassen. D.h. in deinem Fall mit den Texten musst du in allen Objekten prüfen ob abhängige Tabellen- Felder und Variablen, die mit diesen Feldern benutzt werden auch 40 Zeichen lang sind. Und natürlich ist die Basis für alle Entwicklung hier die Version mit der der Kunde gerade arbeiten. Während der Entwicklung arbeitest du mit 3 Datenbanken Kunde 2.6, 4er- Zwischenstand und 2009er- Endversion.

Gruß, Fiddi

Also ich habe alles nochmals druchgeschaut aber ich bleibe immer am gleichen Ort hängen

Mein Vorgehen:
1. NF2.60 starten -> original-DB Kunde öffnen , DB prüfen und alles kompilieren.
2. von der oben geprüften DB ein Backup anlegen (dbOld_cust.fbk)
3. NF Client schliessen
4. Kopie der obigen DB anlegen für die Weiterberarbeitung (dbOldinAttain_cust.fdb)
5. MBS 4.0 Client öffnen , die vorhin erstelle DB (dbOldinAttain_cust.fdb) öffnen und konvertieren.
6. im Object-Designer alle Objekte erneut kompilieren
7. alle Objekte als Textfile exportieren (ObjectsID_cust.txt)
8. Kopie der Original-DB (Cronus) von NF2.60 machen (dbOldinAttain_base.fdb)
9. Diese DB (dbOldinAttain_base.fdb) wiederum in MBS 4.0 öffnen und konvertieren
10. nach dem kompilieren wiederum alle Objekte exportieren in ein Textfile (ObjectsID_base.txt)
11. mit dem Tool "remid" die beiden vorher erstellen Textfiles umwandeln
ObjectsID_cust.txt -> ObjectsNOID_cust.txt
ObjectsID_base.txt -> ObjectsNOID_base.txt
12. Im MBS 4.0 Demodatenbank - Cronus aufrufen und im Object Designer alle Objekte kompilieren und anschliessen wieder alle Objekte als Textfile (dbNew_base.txt) exportieren.

Mergeprozess mit Microsoft Business Solutions-Navision Developer's Toolkit (NDT)

13. neue genügend grosse DB (ndt.fdb) im MBS4.0 erstellen und in den Objectdesigner wechseln. Nun die DevTool.fob importieren und einen neuen Mandanten (ndt) erstellen, Client schliessen
14. die soeben erstellte DB im NDT öffnen und die vorher erstellten Textdateien
(ObjectsNOID_cust.txt, ObjectsNOID_base.txt und dbNew_base.txt) miteinander einlesen und mergen in New_CUST. Alle Konflikte noch beseitigen, resp. kontrollieren und korigieren.
15. Alle Objekte aus dem NDT NEW_CUST als Textdatei(en) exportieren
16. MBS 4.0 Cronus Kopie (dbNew_Cust.fdb) erstellen und im MBS 4.0 öffnen
17. Die vom NDT erstellten Textdatei(en) importieren
18. alle Objekte kompilieren
19. alle Objekte exportieren als cust_objects.fob

Upgrading der alten Datenbank

20. neue DB erstellen im MBS 4.0 (dbNew_custOrig.fdb) (Grösse mind. 2 mal Originalgrösse vorher)
21. Datensicherung aus Pkt. 2 (dbOld_cust.fbk ) importieren und in den Object-Designer wechseln
22. Importieren von "Upgrade260400.1.fob" (W1) + W1CH_Upgrade260400SP2.1.fob

und hier passierts dann ich kann die W1CH_Upgrade260400SP2.1.fob nicht importieren auch nicht mit Replace all -> Fehler: Sie können nicht den Typ des Feldes Text (in der Tabelle G/L EntryI nicht löschen oder ändern, bevor Sie das Feld nicht in allen Datensäten auf 0 .... etc.

Besten Dank für Eure Hilfe
Gruss Alex

Also mir scheint das ganze etwas kompliziert. Mir liegt das NDT allerdings nicht besonders

ich würde für das Merge folgendermaßen vorgehen:
1. Eine FBK aus der Kunden-DB ziehen. Nicht die Objekte der Kunden-DB kompilieren, das kann Unheil anrichten, wenn du nicht genau weißt was da vorher abgelaufen ist.
2. Neue DB (DB1) aufbauen mit dem 4er-Client, und dort die FBK einlesen. (Falls der 2009er Client die FBK öffnen kann, kannst du die FBK auch gleich mit dem 2009er einlesen, und Schritt 3 sparen)
3. Die eben erstellte DB mit dem 2009er-Client öffnen und konvertieren (damit alle mit dem gleichen Text- Format dargestellt werden)
4. Aus der DB1 solltest du jetzt alle Objekte exportieren, und damit eine neue DB (DB2) aufbauen.
5. DB1 solltest du jetzt mit eine ZIP- Tool sichern, du wirst sie sicher noch einige Male benötigen
6. Für diese DB solltest du einen Server-Dienst einrichten, damit du mehrere DBs gleichzeitig öffnen kannst.
7. Jetzt benötigst du eine 4er Cronus (DB3), die du ebenfalls mit dem 2009er Client öffnest und konvertierst
8. Für diese DB richtest ebenfalls eine Dienst ein.
9. jetzt nimmst du eine 2009er DB (DB4) und richtest auch hierfür einen Dienst ein.
10. jetzt kannst du alle 3 Datenbanken gleichzeitig öffnen.
11. Aus allen DBs exportierst du jetzt die Tabelle Field mit einem Dataport, so das du die Daten später vergleichen kannst (IDs, und Captions, Größe, Typ).
12. Jetzt kannst die 3 Dateien hoffentlich vergleichen, damit du die Felder, die du in 2 angepasst hast (Feldgrößen, Kundenfelder), auch in den anderen Versionen anpassen kannst (deshalb die 3 DBs mit den Servern).
13. Alle Kundenfelder und Feldanpassungen, die du für Wert erachtest, auch in der neuen Version vorhanden zu sein, notierst du dir. Du solltest allerdings auch prüfen, ob die Kundenfelder nicht schon in 2009 vorhanden sind bzw. noch benutzbar sind.
14. Jetzt musst du herausfinden, wo die Feldanpassungen in 2.6 verwendet werden und wie sie in 2009 verwendet werden müssen (Tabellenfelder, Variablen). Da die Unterschiede zwischen 2 und 2009 teilweise sehr groß sind (Artikelposten in 2 und Artikel- u. Wertposten in 2009) kann das schon sehr aufwendig werden. Hier hilft dir auch kein Merge, da der nur Code konvertieren kann, der auch in 2.6 vorhanden war. Neuen Code wird der Merge nicht finden. Da ist Handarbeit angesagt
15. Alle Tabellenfeldanpassungen, die du in 2009 gemacht hast, musst du jetzt auch in die 4er- DB übernehmen.
16. Jetzt liest du das UGT Step1 2.6->4 in DB1 ein, und passt das UGT ein. (Feldgrößen in den Sicherungstabellen des UGT. Felder, die in 2009 nicht mehr benötigt werden, aber deren Informationen in 2009 benötigt werden, in Sicherungstabellen sichern, nicht mehr benötigte Felder in DB1 löschen)
17. Jetzt Step1 des UGT laufen lassen. Bevor du das UGT löschst, die Objekte des UGT exportieren und in DB2 einlesen (du wirst sie wahrscheinlich noch benötigen )
18. Wenn du alles richtig gemacht hast, kannst du die Tabellen- Objekte aus DB3 einlesen, ohne das du die Fehlermeldung bekommst, die du unten aufgeführt hast.
19. Da Schritt 18 wahrscheinlich nicht beim ersten mal funktionieren wird, musst du den Grund herausfinden und abstellen (in deinem Fall kann das ein zu kleines oder nicht mehr vorhandenes Feld in 4 (DB3) sein). Dazu passt du entweder die Feldgröße in DB3 an, und importierst die Objekte aus DB3 neu; löschst mit einem Report das nicht mehr benötigte Feld und korrigierst das UGT in DB2; oder sicherst das Feld in einer der Sicherungstabellen des UGT, löschst das Feld und passt ebenfalls das UGT in DB2 an. Danach geht es weiter mit Schritt 18 bis kein Fehler mehr auftritt.
20. UGT Step2 2.6->4 in DB1 einlesen (Ohne schon vorhandene Tabellen)
21. UGT Step2 anpassen, damit die in Step1 zusätzlich gesicherten Daten in den UGT-Tabellen wieder zurück in die eigentlichen Tabellen übernommen werden.
22. UGT Step2 2.6->4 laufen lassen. Vor dem löschen des UGT, die UGT- Objekte exportieren und damit sichern.
23. UGT Step1 4->2009 in DB1 einlesen und laufen lassen. (wenn du die Konvertierung der Kunden- Daten schon beim Upgrade von 2.6 nach 4 gemacht hast, sind hier u.U. keine Anpassungen mehr nötig)
24. Falls du Anpassungen am eben eingelesenen UGT gemacht hast, dieses vor dem löschen der Objekte exportieren.
24. Die Objekte aus DB4 in DB1 einlesen. Falls das schief geht, wie in Schritt 19 verfahren.
25. UGT Step2 4->2009 in DB1 einlesen und laufen lassen.
26. Anwendung testen, testen, testen
27 Bei Fehlern in den Daten fängst du wieder mit dem extrahieren der DB1 aus der in Schritt 5 gesicherten DB an und machst bei Schritt 6 weiter, nur das du die gesicherten UGTs einliest korrigierst laufen lässt und wieder sicherst. Wenn du noch eine Sicherung einer DB aus den Zwischenschritten hast, kannst du evtl wieder bei einem der Zwischenschritte einstiegen, und von dort fortfahren.

So, ich hoffe du verstehst meine Vorgehensweise, und ich habe nicht allzu viel vergessen
.
Ich würde von einem Merge von 2.6 nach 2009 absehen, da aus meiner Sicht die Unterschiede zu groß sind. Übernimm die nicht in 2009 schon vorhandenen Kundenanpassungen in den 2009er Code. Achte auf die Unterschiede zwischen 2.6 und 2009 bei der Übernahme der Anpassungen. Konvertiere die Daten wie oben beschrieben.

Gruß, Fiddi

Hallo Fiddi

herzlichen Dank für deine sehr ausführliche Beschreibung.... ich werde mir dies morgen so mal ausprobieren
vorab noch zwei kleine Fragen zu deinen Punkten:
5. DB1 solltest du jetzt mit eine ZIP- Tool sichern -> ist da einfach ein normales Ziptool ?
11. Aus allen DBs exportierst du jetzt die Tabelle Field mit einem Dataport -> ähm wo finde ich diese Tabelle? Hast du mir eine ID? Oder wie mache ich dies?

Gruss Alex

Zu 5.: man kann einfach das ZIP- Tool von Windows nutzen oder wenns gut komprimiert sein soll z.B. 7-Zip.
Zu 11.: gib den Namen einfach als Tabelle beim Form bzw. Dataport an;).

Gruß, Fiddi

merci Fiddi!! dank deinen Instruktionen bin ich doch nun ein ziemliches Stück weitergekommen

Ich kann die W1CH_Upgrade260400SP2.1.fob importieren und auch ausführen, doch jetzt kommt ein neuer Fehler beim Import und zwar findet er das TableData 91704 nicht und ich sehe dass er bei der Table Item steht s.A.
ich habe bei den Cronus-DBs geschaut aber auch hier gibt es dies TableData nicht ... oder blöd gefragt von mir was ist ein TableData?

Gruss Alex

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

Nun TableData sind die eigentlichen Daten in NAV.

Die Ursache für deine Fehlermeldung ist wahrscheinlich der Schalter "DataperComapny" in der Tabelle. Die Daten in dieser Tabelle sind in der ursprünglichen DB Mandantenübergreifend in der neuen aber nicht bzw. umgekehrt.

Gruß, Fiddi

Habe das Property umgestellt -> leider immer noch der gleiche Fehler

Also ich bin mir jetzt nicht ganz sicher: Wenn die ursprüngliche DB "DataPerCompany" = no hat, müssen auch die neuen FOBs die gleichen Einstellung haben. Versuch mal die Objekte häppchenweise einzuspielen, um herauszufinden welches Objekt die Fehlermeldung verursacht.

Gruß, Fiddi

es sind beide auf Yes gestellt.

frage wie stelle ich es an Objekte häppchenweise einzuspielen resp. wie meinst du dies genau?

wie stelle ich es an Objekte häppchenweise einzuspielen resp. wie meinst du dies genau?

ganz einfach: Du filterst das Import Form auf z.B. Type 'Table' und ID '..30', usw. bis der Fehler auftritt.

Gruß, Fiddi

So, habe es gfunden. Es war nicht wie vermutet in der Tabelle "Item" sondern in der CU 171504 "Upgrade to C4.00" welche im UGT Step 1 vorhanden ist. Dort verwies eine lokale Variable auf die Tabelle 91704 (WebshopTranslation)... kennt jemand diese Tabelle? Ich habe Sie auch nicht im Cronus gefunden. So zum Versuch habe ich diese Zeile auskommentiert, danach konnte ich wenigsten den Step 1 ohne weitere Meldungen abschliessen.

Beim laufen lassen des UGT 2 habe ich aber nun noch viele solcher "verwaister" Tabellenzugriffe -> @Fiddi: hast du dies gemeint mit UGT anpassen, sprich dass ich hier unter Umständen ganze Funktionen rausnehmen muss in den entsprechenden Codeunits? Oder ging etwas grundsätzlich schief?

Gruss Alex

Hallo Alex,


also in der Regel wird das UGT eher größer, nicht kleiner . Das UGT hat eigene Tabellen dabei, kann es sein das du Probleme damit hast, ich weiß gerade nicht in welchem Nummernkreis die liegen. Kann es sein,das du nicht das originale UGT von MS verwendest, sondern eins, was mal von eurem Partner gekommen ist? Mit Webshop hat zumindest die deutsche bzw. W1- Version von >= NAV 4.0 nichts mehr am Hut. Sollten da noch irgendwelche Leichen vom Commerce- Portal oder irgendwelche Branchenlösungen herum fliegen, musst du diese erst einmal eliminieren bzw. dir die neue Version der Branchenlösung, bzw.- deren Upgradetoolkit in NAV2009 besorgen. Commerce- Portal gibt es in so NAV2009 nicht mehr. Hast du es verwendet, musst du dich jetzt nach einer anderen Lösung dafür umschauen.

Das ganze scheint mir doch nicht nur eine einfache Standard NAV2.6 Installation zu sein, die da upgedatet werden soll. Da ohne de Code der einzelnen Versionen gesehen zu haben, zutreffende Tipps zu geben wird langsam schwierig Zu mal es sich bei deiner DB auch wohl um eine Schweizer Version handeln dürfte, die sich doch von der mir bekannten Deutschen Version erheblich unterscheidet.

Gruß, Fiddi