[Gelöst]Update von Navision 3.6 auf Nav 2009

Hallo Zusammen
ich versuche mich zur Zeit testweise an NAV2009 heranzuarbeiten, Wir haben eine Native Datenbank Navision Attain 3.6 Größe 50GB unser Navision ist von uns erweitert worden (spezielle Anwendung im Lager, Debitoren, Verkauf ) nur FiBu ist noch Original. Jetzt meine Frage können wir von 3.6 auf Nav 2009 Nativ wechseln und wie müssen wir vorgehen, von 3.6 auf 3.7 wechseln und Datensicherung einspielen. Und wie von 3.7 auf 2009 ?.

Hat jemand irgendwelche Infos, die mir bei meinem Problem weiterhelfen. Schon jetzt herzlichen Dank für jedwede Antwort.
Vielen Dank.
mfg
Hilton

Zuletzt geändert von Hilton am 21. März 2011 11:25, insgesamt 1-mal geändert.

Die erste Frage die sich stellt: wollt ihr ein rein technisches Update oder Objekt-Update machen?

Rein technisches Update neuen Server neue Clients mit Windows 7

Hallo,

für ein technisches Update von NAV3.60 zu NAV2009 gibt es folgende Varianten:
a) in NAV3.60 eine Komplettsicherung (fbk) der Datenbank erstellen und diese Datensicherung in eine neue Datenbank (mit NAV2009 erstellt) importieren
b) die bisherige NAV3.60-Datenbank (am besten eine Kopie der Original-Datenbank) mit dem NAV2009-Client öffnen und die Datenbank konvertieren

Dadurch hättet ihr das technische Update der Datenbank abgeschlossen.
Danach solltet ihr den bisherigen Native-Datenbankserver (NAV3.60) und eventuell vorhandene Applicationserver deinstallieren und die jeweiligen Versionen für NAV2009 installieren.
Anschliessend alle Clients (NAV3.60) deinstallieren und die neuen Clients (NAV2009) installieren.

wichtig: ihr solltet vorher prüfen, ob in eurer NAV-Lizenz das Granule für NAV2009 freigeschaltet ist. Falls nicht, müsst ihr bei eurem Navision-Partner eine aktualisierte Lizenz anfordern.

Gruß
Jörg

Hallo,

außerdem solltet ihr prüfen, ob ihr in NAV 3.6 irgendwelche Integrationen nutzt (Office, Commerce Gateway,....). Bei denen ist keinesfalls sichergestellt, das die nach der Umstellung noch funktionieren. MS gewährt keinen Support auf dieses technische Update, da es explizit ausgeschlossen wurde von Versionen <=5.1 ein technisches Update nach 2009 zu machen.
Wenn dieses oft trotzdem funktioniert, liegt das meist daran, dass nur NAV und keine externen Anbindungen genutzt werden

P.S.: Solltet ihr bei der Gelegenheit auf SQL umstellen wollen (was bei der DB- Größe sicherlich eine gute Idee ist), dürft ihr nicht vergessen vor dem erstellen der FBK in der alten DB den Fieldcheck laufen zu lassen. Der prüft z.B., ob eure Datumsfelder nur Werte <1.1.1756 enthalten. Falls ja (was zu erwarten ist ) müssen diese korrigiert werden, weil die SQL-DB diese FBK sonst nicht verarbeiten kann.

Gruß, Fiddi

Hallo
vielen Dank für eure Antwort
Ich werde das ganze jetzt einmal testen und den Zeitaufwand festhalten.
Zu Euren Fragen
Jörg : Wir haben eine neue Lizenz für 2009
Fiddi : Wir haben nach Rücksprache mit unseren Navision Partner beschlossen wieder die Native Datenbank zu benutzen.
Pararell müssen wir auch unseren Nas Server neu installieren (Verbindung Webshop)

Bei Commercegateway bitte folgendes beachten.

Gruß, Fiddi

Und nochwas:

Die Sortierung von "Code" Feldern ändert sich:
vorher 1,2,3,4,5,6,7,8,9,10,11,...
nachher: 1,10,11,2,20,3,30,...

Das kann zum Problem werden; insbesondere wenn Filter (z.B. im Kontenplan) falsch abreifen; z.B. 1..10:
vorher: 10 DS (1,2,3,4,5,6,7,8,9,10)
nachher: 2 DS (1,10)

Das kann man mit der Eigenschaft "SQLDataType" regeln, aber ist ggf. auch mit "Wenn & Aber" verbunden ... muss man diskutieren.

@Stryk:

Wir haben nach Rücksprache mit unseren Navision Partner beschlossen wieder die Native Datenbank zu benutzen

Gruß, Fiddi

Ups, das hab' ich überlesen

Warum die native Datenkbank?
Wäre es nicht sinnvoller die Umgebung auch Objekttechnisch zu updaten und so für die neueren Version gerüstet zu sein? Klar der Aufwand liegt auf der Hand, aber sicherlich gibt es viele Vorteile. Spätestens bei 7.0 wird es lt. Infos keine native Unterstützung mehr geben.

Selbst die Legals zu MwSt 2010 wurde von MS nicht mehr für 3.6 bereitgestellt. Ein einfaches Downgrademerge eines solchem Legal ist nicht trivial.

Hallo Board

Auf die Frage von BlackJack warum Wir bei der Nativen Datenbank bleiben kann ich nur sagen der Aufwand auf eine SQL Datenbank ist zu groß,
Wir haben eine selbst Entwickelte Navision unser Objekte weichen vom Standard zu 80 % ab.
Außerdem müsste unser Admin erst auf eine SQL Schulung gehen. Da wir noch nicht mit einer SQL Datenbank arbeiten.

mfg
Hilton

Was hat der Objektstand denn mit der verwendeten Datenbank zu tun? o_O

Der einzige Unterschied ist, dass bei der Programmierung ein wenig aufgepasst werden muss um performanter zu werden.

Hallo,

Der einzige Unterschied ist, dass bei der Programmierung ein wenig aufgepasst werden muss um performanter zu werden.

Da kann ich dir nur voll zustimmen. Es ist allerdings so, das die native DB schlechte Programmierung u.U. etwas eher toleriert als der SQL-Server. (was der SQL-Server anscheinend nicht mag sind Flowfields in Tabellen, die mit Flowfiltern belegt sind, und dann noch auf dieses Flowfield filtern. Außerdem habe ich jetzt gerade gesehen, wie ein einziger Report einen neuen SQL-Server mit 8 Kernen auf 85 % Auslastung bringt )

Gruß, Fiddi

Außerdem habe ich jetzt gerade gesehen, wie ein einziger Report einen neuen SQL-Server mit 8 Kernen auf 85 % Auslastung bringt

Den SQL-Server oder die Reporting-Services?

Volker

Hallo Board
Also mein Testserver mit NAV 2009 Nativ läuft.
Das mit den SQL Server werde ich jetzt einmal testen
mfg
Hilton

Den SQL-Server oder die Reporting-Services?

da es ein NAV- CC- Report war, den SQL-Server Ich vermute (die Programmierung stammt nicht von mir), dass dort intensiv gefilterten Flowfields gearbeitet wird (z.B. Item.calcfields(Inventory); Item.Setfilter(Inventory,'<100') wobei das ganze noch nach LAgerort gefiltert wird), das mag der SQL anscheinend nicht so gerne

Gruß, Fiddi