Update NAV 4.0 SP3 auf NAV 5.0 SP1

23. Juli 2008 12:26

Hallo,

wahrscheinlich greife ich das Thema zum x ten mal auf.
Jedoch habe ich durch die Suche nur allgemeiner Angaben gefunden.
Keine Leitfäden? Gibt es solche Anleitungen?
Ansonsten habe ich mir Informationen zusammen gesucht:

Ich habe die Aufgabe bekommen unsere Navisiondatenbank von der jetzigen Version 4.0 SP 3 auf die neue Version 5.0 SP 1 umzustellen.

So wie ich das verstanden habe gibt es hierbei 2 Schritte zu beachten:

1. Technical Update: Öffnen der Datenbank(4.0 SP3) mit Navision(5.0
SP1). Frage nach Konvertierung bejahen.

2. Manuelle Anpassung: Alle Anpassungen, welche man an der alten
Datenbank(4.0 SP3) durchgeführt hat,
müssten wieder erstellt werden.

Diese Informationen habe ich von [url]http://www.mibuso.com/forum/viewtopic.php?t=26826&highlight=update+++sp3+++sp1]mibuso[/url]

habe ich die Informationenn richtig zusammen gefasst, oder liege ich komplett daneben?

Ich würde mich über Antwort freuen. Ansonsten vielen Dank.

Gruß Heiko_D

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

3. August 2008 21:30

Die Vorgehensweise ist grundsätzlich richtig.
Beim einem Hauptversionssprung ist es außerdem ratsam, das +Upgrade +Toolkit zu verwenden.

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

5. November 2008 16:19

Danke für die Antowort.
Nach langer Zeit hatte ich wieder Gelegenheit, mich mit dem Update auseinander zu setzen.
Jedoch gibt es nun ein neues Problem. Ich hoffe Ihr könnt mir weiterhelfen.

Ich habe nun den Merge Prozess durchlaufen lassen.
Hierfür war es nötig, dass ich angebe, welches meine aktuelle 4.0 SP3 Datenbank ist, die Standart 4.0 SP3 Datenbank und die Standart 5.0 Datenbank.
All diese Objecte mussten für den Merge Prozess angegeben werden. Anscließend exportiert man alle Objecte aus der neu entstandenen Version in eine txt datei und importiert diese in eine neue 5.0 DB. In dieser neuanlgelegten DB muss man vorher aber noch die ursprünglichen daten aus der 4.0 aktuellen daten bank importiern und form 10400 durchlaufen lassen. Dies löscht alles bis auf die Tabellen.
Nun will ich die Objecte aus dem Merge Process importieren.
Jedoch komme ich nicht weit:
Siehe Anhang.
(Ihre Programmlizens reicht nicht aus, um die Tabelle Country zu erstellen)

Liegt das daran, diese Tabelle zu den Systemtabellen gehören und nicht verändert werden dürfen?
Wenn ja, wie soll man dann die Objecte aus den Merge Prozess einfügen?
Wir verwenden doch eine Lizenz, in der wir in Navision 5.0 arbeiten dürfen?
Was mache ich flasch, bzw wie komme ich weiter?

Ich bitte um eure Hilfe.
Danke

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

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

5. November 2008 18:11

Heiko_D hat geschrieben:In dieser neuanlgelegten DB muss man vorher aber noch die ursprünglichen daten aus der 4.0 aktuellen daten bank importiern und form 10400 durchlaufen lassen. Dies löscht alles bis auf die Tabellen.


Letzteres (die Tabellen bleiben in der DB) ist der springende Punkt: d.h. (wimre) die werden durch den txt-import bestenfalls überschreiben. Eine 'ich-darf-alles'Lizenz (Entwicklerlizenz) ist aber nie verkehrt ;-)

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

5. November 2008 23:32

Hallo!

Zum Ablauf eines Updates wird u.U. folgendes benötigt:
  • - eine NAV-Datenbank die aktualisiert werden soll (in deinem Beispiel NAV 4.0 Sp3)
  • Das passende Upgradetoolkit (UGT) (Denk daran, das es die passende Landesversion und Objektversion ist)
  • Wenn du die deutsche Addon-Datenbank verwendest, benötigst du u.U. noch das Upgrade-TK für den Zahlungsverkehr.
  • Im Normalfall eine Entwickler- Lizenz
  • Ein Programm zum Trennen von Textexporten in einzelne Textdateien pro Objekt (navopjsplitter->mibuso).
  • Ein Programm um die Textexporte der Datenbanken zu Mergen, bzw. Daten zu vergleichen (Winmerge, Beyond Compare, Elliè Computing Merge,...)
  • Einen Objekt- Stand, der die Basis für deine jetzigen und deinen neuen Objektstand ist.
  • Die Objekte für die neue Datenbank 5.0SP1

Zum Ablauf des Updates (meine Vorgehensweise):

  • Es werden Textexporte von den 3 Objektständen (Akt, Basis, Neu) erstellt und mit dem Splitter aufgetrennt.
  • Danach baue ich mir drei Datenbanken auf
    • jetziger Objektstand mit UGT Step1 [DBo](je nach Datenbankgröße evtl. eine Kopie der aktuellen Datenbank, wenn`s geht als Server installieren)
    • eine Datenbank mit dem neuen Basis- Objektstand und UGT Step2 [DBn]
    • Eine Datenbank zum Testen des Updates[DBt]
  • Jetzt werden alle Felder gesucht, die in der neuen Version nicht vorkommen. (das kann man mit einem Dataport auf die Tabelle Field in alter und neuer Datenbank erreichen, die man miteinander vergleicht). Die Standardfelder solltest du ignorieren können, die sollte Step1 des UGT bearbeiten. Die Felder, die sonst nur in deiner Datenbank enthalten sind, musst du dir ansehen. Für jedes dieser F elder musst du klären, ob diese in der neuen Datenbank noch benötigt werden, bzw. ob diese so noch verwendet werden können. Wenn das Feld so weiter verwendet werden kann, musst du es auch im neuen Objektstand [DBn] anlegen. Ist das Feld in der neuen DB nicht mehr, oder anders zu verwenden, musst du es im UGT Step1 [DBo] in einer Tabelle sichern, die weder im alten noch im neuen Objektstand verwendet wird, diese gehört dann zum UGT.
  • Hat man Felder in Step1 gesichert, muss man Step2 [DBn] so anpassen, das er die gesicherten Felder in den neuen Objektstand konvertiert (in diesem und dem vorherigen Schritt kommst du ohne Entwickler-Lizenz sicher nicht weiter)
  • Jetzt sichere ich zunächst das UGT Step1 aus [DBo] und den den kompletten Objektstand aus [DBn]
  • UGT Step1 wird nun in [DBt] eingespielt und durchgeführt.
  • Wenn das durchgelaufen ist, versuche ich den neuen Objektstand und das UGT aus [DBn] einzuspielen, uns zwar mit ' Replace All' und nicht mit mit 'Merge'. Das geht erfahrungsgemäß beim ersten mal schief, weil Felder im Step1 nicht gelöscht oder korrekt konvertiert wurden.
  • Hat man endlich geschafft, den neuen Objektstand und UGT Step2 ind [DBt] einzuspielen, kann man versuchen Step 2 durchzuführen.
  • Wenn Step2 durchgelaufen ist, hat man jetzt eine neue Datenbank mit konvertierten Daten.
  • Geht bei Step1 oder Step2 etwas schief, werden die UGTs in [DBo], [DBn] und [DBt] entsprechend angepasst, damit Sie für den Echtlauf korrekt sind.
Das war jetzt die halbe Miete. Du hast jetzt eine Datenbank, deren Daten auf dem neuen Stand ist. Ist deine Datenbank etwas größer, kannst du während Step1 bzw. Step2 durchlaufen, schon mal mit dem eigentlichen Mergen des Objektstands anfangen.
Hier gibt es verschiedene Vorgehensweisen um die Progammänderungen aus deiner Datenbank in den neuen Objektstand einzubauen.
  • Ein Weg ist das Developers Toolkit von NAV. Es ermöglicht den Merge von zwei Programmständen zu einer neuen Version. Leider hat mein Kollege (der hat's mal benutzt) ein paar Probleme mit dem gehabt, was da raus gekommen ist (es wurden Daten verändert und gelöscht).
  • Eine weitere Methode ist das "Navision Mergetool PM??" (Mibuso). Hierzu kann ich keine weitere Auskunft geben.
  • ich persönlich bevorzuge die Methode mit einem Text- Merge- Tool zu arbeiten, das den reinen Textexport analysiert. Dazu vergleichst du die gesplitteten Textexporte aus [DBo], [DBn] und Basis miteinander, um herauszufinden, welche Änderungen du an deiner Datenbank gegenüber dem Standard vorgenommen hast. Diese Änderungen (Formdesign, Reports,Programmanpassungen,..) musst du jetzt in die Kopie der Textdateien deines neuen Objektstandes einbauen. Die Textdateien, die daraus entstanden sind, werden jetzt mit dem Splitter wieder zu einer Textdatei zusammen geführt.
    Die Textdatei wird jetzt in [DBn] eingelesen und alle Objekte anschließend kompiliert (das geht meistens nicht beim ersten mal). Die neuen Objekte aus [DBn] kannst du jetzt als Objektstand für deine zukünftige Datenbank verwenden.

Wie du siehst, ist es nicht damit getan, eine neuen Objektstand in deine Datenbank per 'Merge' einzuspielen und die UGTs durchzuführen. Das funktioniert evtl. nur mit der Cronus- Datenbank von der NAV-CD.
Wenn du irgendwelche Anpassungen an deiner NAV-Datenbank vorgenommen hast(Form,Reportdesign,..), oder du eine Branchenlösung einsetzt, brauchst du ein UGT, das auf diese Anpassungen abgestimmt ist. Da die Konvertierung mit dem UGT sehr komplex ist, ist es ratsam in einer Testdatenbank die Konvertierung und den neuen Objektstand ausführlichst zu testen, bevor man das ganze mit der Echt- Datenbank durchführt.

Gruß, Fiddi

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

6. November 2008 16:14

Zum Thema neue Felder im Standardnummernbereich anlegen siehe auch hier.

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

7. November 2008 18:22

Erst einmal vielen Dank für eure Antworten.

Nun jedoch bitte etwas langsamer:

was meinst du mit UGT Step1 oder Step2? Ist das ein Dokument ?
und dann daraus der Scritt 1 bzw Schritt 2?

Und wie wird "Winmerge" eingesetzt?
Ich habe versucht basis (4.0 SP3) und neu (5.0) gegenüberzustellen. Jedoch funktioniert dies nicht. Ich denke dies liegt daran, dass "Winmerge" keine Navisondaten kennt und die so auch nicht anzeigen kann.

Vielen Dank für eure Hilfe.

Gruß,
Heiko_D

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

7. November 2008 19:27

Hallo Heiko_D!t t

Ich glaube, ich muss noch ein wenig weiter ausholen, um dir zu zeigen, wa alles zu tun ist.

NAV ist leider keine Anwendung für die man wie bei Office oder vielen anderen Anwendungen, ein neues Programm bekommt, es mit Setup installiert, und danach hoffst, das noch alles funktioniert.
Bei NAV läuft das meitens :-) ein wenig anders. Da NAV in der Regel an den Kunden, der es benutzt, angepasst wird, wirst du sicherlich in deiner aktuellen Anwendung angepasste Berichte oder Formulare finden. Diese Objekte müssen in den Programmstand der neuen Version überführt werden. Ich denke du willst nicht auf die in angepassten Belege verzichten :!: :?: . Dies ist der eine Teil der Arbeit. Dazu benötigst du den TEXT - Export der Navison- Objekte der zwei bzw. drei Versionen, die du mit dem erwähnten Splitter aufteilen kannst. Wenn du das gemacht hast, kannst du die Objekte deiner aktuellen Datenbank in den neuen Stand von Hand überführen (dazu verwendest du die erwähnten Mergetools, Anleitungen siehe bei dem jew. Tool). Damit das nicht in die Hose geht, solltest du aber über einige Erfahrung in der Navision-Prgrammierung verfügen :!: :!: :!: :!: .
Der zweite Schritt ist die Konvertierung der Daten(Tabellen) aus der alten Version in die neue Version. Dazu benutzt man das von Natalie erwähnte Upgrade Toolkit (UGT). Dieses Toolkit sorgt dafür das Datenfelder aus deiner akt. Version (4.0), die es so in der neuen Version (5.0) nicht mehr gibt oder anders verwendet werden, konvertiert werden. Das UGT befindet sich i.d.R auf der CD der neuen Version. Dort finden sich mehrere Versionen des Toolkits. Man muss sich immer die zu seinem Update passende Version suchen (hier 4.0 SP3->5.01). Das UGT besteht aus zwei Teilen Step1 und Step2. Auch diese Objekte müssen u.U. an deine Datenbank angepasst werden, damit Daten, die speziell für euch in eurer Datenbank angelegt wurden, durch das Update nicht verloren gehen. Step1 des UGT wird im aktuellen Datenbestand (4.0) eingespielt und ausgeführt (Das von dir ausgeführte Form 104000 ist Bestandteil des UGT). Danach werden die gemergten Objekte und UGT Step2 eingespielt und das UGT Step2 ausgeführt. Wenn das alles passiert ist, und dir beim konvertieren der Date und Programme kein Fehler unterlaufen sind, hast du jetzt eine NAV 5.0 Sp1 mit deinen Anpassungen.

Gruß, Fiddi

P.S.: wenn du weitere Infos benötigst: In diesem Forum und bei Google weitere Informationen zu diesem Thema

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

12. November 2008 18:39

Vielen dank dass ihr versucht mir die einzelnen Schritte zu erklären.
Jedoch habe ich auch diesesmal ernste Probleme mit der Thematik.
Bitte habt Nachsicht mit einem Unerfahrenem.

So wie ich es verstanden habe, soll das Upgrade durch mehrere Schritte erfolgen und nicht wie es von Microsoft geschrieben wird, einzig und allein vom Upgrade Tool Kit + den beiden fob dateien (Upgrade400500.1.fob und Upgrade400500.2.fob).

Benötigt wird für das Projekt folgendes:
-Alle Objecte der beteiligten Versionen im txt Format. (basis(4.0 SP3); aktuell(4.0 SP3) ; new(5.0))
-Winmerge (zum Vergleichen + hinzufügen erstellter Änderungen in der aktuellen Version zur newbase Version)
-Nav Splitter (zum Auflösen der Objecte aller Versionen in einzelne txt dateien, damit der Vergleich mit Winmerge einfacher ist)
-Upgrade Toolkit (automatisches Angleichen der Standardobjecte der aktuellen Version an die new Version)
-Entwicklerlizens

Ablauf:
-Die txt Dateien der basis, aktuell und new werden mit dem Navision Splitter in einzelne txt Dateien pro Object unterteilt.
-Kopieren der aktuellen Datenbank und einfügen des Upgrade400500.1.fob. Ausführen der Upgrade400500.1.fob "Transfer Objects"
-Anlegen einer neuen Datenbank mit der 5.0 Version + Import von Upgrade400500.2.fob.
-Mit Hilfe von Winmerge werden die einzelnen txt Dateien ,der aktellen Version, welche mit dem Splitter erzeugt wurden, mit der
der new Version verglichen. Jeodch nicht alle, sondern nur jene, an welchen Anpassungen vorgenommen wurden.
Diese angepassten Objecte der new Version werden wieder mit dem Nav Splitter zusammengefügt.
-Um die nicht wie im letzten Schritt bearbeiteten Objecte upzugraden, benutzt man das Windows Tool Kit. Hier erstellt man neue
Import Versionen mit Hilfe der txt Dateinen aller drei Versionen. Anschließend startet man den Merge Prozess. Ist dieser fertig,
so werden die so neu angelegten Objecte in eine txt Datei exportiert.
-Nun importiert man die aus dem letzten Schritt erstellte txt Datei in die angelegt 5.0. Anschließend wird die bearbeitete txt Datei von Winmerge, welche wieder mit dem Nav Splitter zusammengefügt wurde ebenfalls in die angelegte 5.0 Version
-Der letzte Schritt ist das Ausführen des Upgrade400500.2.fob.

Jedoch kommt wieder die Einschränkung, welche ich in meinem vorherigen Beitrag erwähnt habe.
"Sie habe keine Berechtigung.... ", was jedoch mich verwundert ist, dass dies Meldung nicht immer an der gleichen Stelle erscheint, sondern auch einmal die gesammten Tabellen importiert hat, dann jedoch bei den Forms meinte, dass ich keine Berechtigung hätte gewisse Objecte zu erstellen.

Darum wollte ich wissen, ob Ihr mir sagen könnt, ob ich mit der Reihenfolge des Vorgehens Recht habe, oder ob ich schon von anfang an einen gewichtigen Fehler gemacht habe.

Im Vorraus bedanke ich mich für eure Mühe.

Gruß,

Heiko_D

Re: Update NAV 4.0 SP3 auf NAV 5.0 SP1

12. November 2008 20:22

Hallo Heiko_D!

Zu dem Benötigten:

  • Die Objekte benötigst du in .txt- und .fob- Form
  • Ich benutze ein Diff3-Tool (Ellié -Merge), das 3 Dateien miteinander vergleichen kann. Das Tool hilft dir bei der Entscheidung, ob es sich um eine eigene Anpassung handelt oder eine Änderung im Standard ist. Hast du keine Basis- Version, kannst du mit WinMerge die alten und neuen Objektstände zusammenführen.
  • Das Upgrade Toolkit konvertiert nur die Daten (sprich den Inhalt der Tabellen) aus dem alten in den neuen Stand. Das aber für alle Daten die sich ändern. D.h. du mußt das UGT auch anpassen, wenn sich Daten in deiner Anpassung von alt nach neu ändern.

Der Ablauf teilt sich in zwei Schritte auf
  • 1. Konvertierung der Daten von alt nach neu mit dem UGT.
  • 2. Übertragung der eigenen Programmanpassungen von alt nach neu.

Zu Schritt 1.:

Bitte führe die beschriebenen Aktionen erst auf deiner Echt-Datenbank aus, nachdem du Sie gesichert hast, und Tests auf einer Testdatenbank problemlos funktioniert haben. Führe Tests nur auf Kopien der Datenbank aus.

  • A. Finde heraus, welche nicht NAV- Standard- Tabellen- Felder deiner aktuellen Datenbank sich in der neuen Version ändern.
  • B. Passe Step 1 und 2 des UGT so an, das deine Daten korrekt von der alten in die neue Version konvertiert werden.
  • C. Führe UGT Step1 auf der aktuellen Version deiner Datenbank aus.
  • D. Spiele die in Schritt 2. entstandenen neuen Objekte in die aktuelle Datenbank als .fob mit 'Replace All' ein. Wenn du dein UGT Step1 richtig angepasst hast, sind jetzt alle in der neuen Version deiner Datenbank nicht mehr vorhandenen Felder leer, oder falls weiter benötigt, in anderen Tabellen gesichert. Solltest du dabei ein Feld vergessen haben, bekommst du sinngemäß die Fehlermeldung "Das Feld XYZ in der Tabelle ABC kann nicht gelöscht werden, weil noch Daten enthalten sind". Dann heißt es, UGT noch mal anpassen und wieder bei A. anfangen bis es klappt.
  • E. Wenn Schritt D. funktioniert hat, darfst du jetzt UGT Step2 ausführen.
  • F. Jetzt prüfe bitte, ob alle deine Daten noch so vorhanden sind, wie du sie benötigst. Falls nicht. beginne wieder bei A. bzw. B. .
  • G. Der nächste Schritt ist das prüfen der eigentlichen Anwendung (funktionieren alle Formulare, Reports,...). Sollte auch das zu deiner Zufriedenheit sein. Hast du es geschaft.


Zu Schritt 2:

  • a. Schaffe die schon beschriebe Testumgebung mit Datenbanken aktueller, neuer und Basis Version ohne UGT.
  • b. Exportiere alle Objekte aller Datenbanken als Text-Datei.
  • c. Teile die Textdateien mit dem Splitter in ein Verzeichnis für jede Version auf.
  • d. Überführe deine Anpassungen und Datenänderungen deiner aktuellen Version in die neue Version für jedes Objekt, das sich von aktuell nach neu ändert.(auch die Felder aus Schritt 1)
  • e. Führe das Ergebnis mit dem Splitter wieder zusammen.Wichtig: Lösche aus deinem Ergebnis- Verzeichnis die Menu- Suiten 10..49 heraus. Die kann man mit einer Entwickler- Lizenz nicht einlesen.
  • f. Versuche die entstandene Textdatei in die Datenbank mit dem neuen Programmstand einzulesen.
    Solltest du jetzt die Fehlermeldung bekommen "Sie habe keine Berechtigung.... ", gibt es zwei Möglichkeiten:
    • Du versucht, in einer Tabelle ein Feld anzulegen, das in der neuen Datenbank nicht mehr enthalten ist. Ist das ein Standard-Feld, hast du bei Schritt d. einen Fehler gemacht. Ist das ein nicht NAV-Feld (Feld-ID 1..49999), benötigst du eine andere Lizenz um die Text-Datei einzulesen. Bei einem NAV-Feld musst du dieses aus deiner Textdatei aus Schritt f. entfernen, evtl. einzelne Objekte aus Schritt d. erneut anpassen und mit Schritt f. weitermachen.
    • Du versuchst ein Objekt (Tabelle,Form,Report, Menu,..) für das du mit deiner Lizenz keine Schreibberechtigung hast anzulegen. Eliminiere das Objekt aus deinem in e. entstandenen Ergebnis, und fahre mit Schritt f. fort. Ist das kein Standard-Objekt, kannst du evtl. mit einer anderen Lizenz das Objekt doch einspielen.
    Das Ganze kann dann sehr kniffelig werden, wenn du in deiner Datenbank Objekte mehrer NAV-Partner hast. Dann kann es sein, dass du das Einspielen der Textdatei in mehreren Schritten mit Entwickler-Lizenzen der Partner durchführen musst oder du von den NAV-Partnern angepasste FOB-Objekte benötigst.
  • g. Solltest du Schritt f. erfolgreich abgeschlossen haben. D.h. du hast eine Datenbank mit der eingelesenen Text-Datei und evtl. angepassten weiteren Objekten. Dann solltest du im Objekt- Designer alle Objekte kompilieren. Dabei werden sicherlich Fehler auftreten, diese musst du jetzt beheben.
  • h. Hast du auch Schritt g. geschafft, solltest du alle Objekte aus dieser Datenbank als .FOB exportieren. Diese .FOB-Datei wird dann in Schritt 1.D. eingelesen.

Dein Problem mit mal geht bzw. mal geht nicht mit den Berechtigungen, kann daran liegen, das du Tabellen z.B. mit Option 'Merge' eingespielt hast. Dann werden keine Felder gelöscht, und darin enthaltene Daten führen nicht zum Abbruch. Für das Update müssen die Objekte zwingend mit 'Replace All' eingespielt werden.. Die zweite Möglichkeit kann in der Verwendeten Lizenz liegen. Arbeitest du mit mehreren NAV-Partnern zusammen, kann es sein, das du Objekte der Partner nur mit einer Entwickler-Lizenz der jeweiligen Partner einspielen kannst.

Gruß, Fiddi