Sinnvoller Versionswechsel
9. Februar 2011 15:21
Hallo,
ich bin neu in einer Firma, in der man den Umstieg einer älteren NAV – Version auf eine neue plant. Zur Auswahl steht die Variante des Umstiegs auf die letztmögliche Version mit der nativen Datenbank oder gleich das upgrade auf die neueste Version mit SQL Server als Datenbankserver.
Könnt Ihr mir Vor- und Nachteile beider Varianten nennen?
Wie schauts mit Zusatzkosten für eine ggf. nötige SQL Serverlizenz aus, braucht man auch neue Hardware?
Macht ggf. der Zwischenschritt über die native Datenbank Sinn, d. h, wann muß ich schätzungsweise sowieso auf SQL – Server umstellen?
Sind die Reports bei der SQL – Servervariante noch zu gebrauchen (ich hab gehört, die sind dann mit Visual Basic programmiert)? Gibt’s sonst noch was umzuprogrammieren beim Umstieg auf die SQL – Serverversion?
Gibt’s Performanceunterschiede dadurch, daß die alte Datenbank nicht SQL – fähig ist, der SQL – Server aber natürlich doch?
Was passiert eigentlich mit dem ganzen Programmcode auch auf den Tabellen, kann der so ohne weiteres konvertiert werden?
Noch ne ganz andere Frage zum Abschluss: täusche ich mich, oder ist NAV irgendwie von MSAccess abgekupfert oder umgekehrt???
Fragen über Fragen…. Vielen Dank schon mal für Eure Antworten
Ria Savoy
ich bin neu in einer Firma, in der man den Umstieg einer älteren NAV – Version auf eine neue plant. Zur Auswahl steht die Variante des Umstiegs auf die letztmögliche Version mit der nativen Datenbank oder gleich das upgrade auf die neueste Version mit SQL Server als Datenbankserver.
Könnt Ihr mir Vor- und Nachteile beider Varianten nennen?
Wie schauts mit Zusatzkosten für eine ggf. nötige SQL Serverlizenz aus, braucht man auch neue Hardware?
Macht ggf. der Zwischenschritt über die native Datenbank Sinn, d. h, wann muß ich schätzungsweise sowieso auf SQL – Server umstellen?
Sind die Reports bei der SQL – Servervariante noch zu gebrauchen (ich hab gehört, die sind dann mit Visual Basic programmiert)? Gibt’s sonst noch was umzuprogrammieren beim Umstieg auf die SQL – Serverversion?
Gibt’s Performanceunterschiede dadurch, daß die alte Datenbank nicht SQL – fähig ist, der SQL – Server aber natürlich doch?
Was passiert eigentlich mit dem ganzen Programmcode auch auf den Tabellen, kann der so ohne weiteres konvertiert werden?
Noch ne ganz andere Frage zum Abschluss: täusche ich mich, oder ist NAV irgendwie von MSAccess abgekupfert oder umgekehrt???
Fragen über Fragen…. Vielen Dank schon mal für Eure Antworten
Ria Savoy
Re: Sinnvoller Versionswechsel
9. Februar 2011 15:53
Hallo RiaSavoy,
zunächst herzlich Willkommen im Forum.
Dann NEIN : Dynamics NAV hat nichts und hatte nie etwas mit MS-Access zu tun.
Nun aber zu deiner eigentlichen Frage: Es wäre schön gewesen, wenn du deine aktuelle NAV- Version angegeben hättest. Ich nehme jetzt mal an, das die Version 4 korrekt ist.
Prinzipiell solltest du heute auf eine SQL-Datenbank umsteigen, und dazu auch passende Hardware wählen (dazu mehr in vielen Beiträgen hier im Forum), da die nächsten Versionen von NAV (Version 2011++) definitiv SQL-Server voraussetzen werden. Ob du jetzt auf RTC umsteigst oder beim CC bleibst ist auch nur eine Frage der Zeit, denn auch dieser Client wird in der Zukunft eingestellt.
Wenn du jetzt auf NAV 2009 umstellst, hast du die Möglichkeit mit relativ wenig Schulungsaufwand (bezogen auf Version 4) auf eine neue NAV- Version im CC umzusteigen. Du hast aber auch schon die Möglichkeit eure Firma Abteilungsweise auf den neuen Client umzustellen, und dabei Erfahrungen mit der neuen Umgebung zu sammeln.
Zu den Lizenzkosten kann man nur schwer etwas sagen, ohne eure Firma, das Datenvolumen und die Benutzeranzahl zu kennen.
Es gibt eigentlich drei Möglichkeiten der Lizensierung:
Zur Performance:
Ein vernünftig dimensionierter SQL- Server kann bei gleicher Hardware durchaus schneller sein, als eine native DB. Das hängt vom Datenvolumen ab und den normal ablaufenden Transaktionen ab. Eine aktueller Server ist mit einer nativen Datenbank heute eigentlich unterfordert, da man mit mehr CPU-Kernen und mehr Arbeitsspeicher nichts ausrichten kann. Beim SQL-Server geht das sehr wohl.
zunächst herzlich Willkommen im Forum.
Dann NEIN : Dynamics NAV hat nichts und hatte nie etwas mit MS-Access zu tun.
Nun aber zu deiner eigentlichen Frage: Es wäre schön gewesen, wenn du deine aktuelle NAV- Version angegeben hättest. Ich nehme jetzt mal an, das die Version 4 korrekt ist.
Prinzipiell solltest du heute auf eine SQL-Datenbank umsteigen, und dazu auch passende Hardware wählen (dazu mehr in vielen Beiträgen hier im Forum), da die nächsten Versionen von NAV (Version 2011++) definitiv SQL-Server voraussetzen werden. Ob du jetzt auf RTC umsteigst oder beim CC bleibst ist auch nur eine Frage der Zeit, denn auch dieser Client wird in der Zukunft eingestellt.
Wenn du jetzt auf NAV 2009 umstellst, hast du die Möglichkeit mit relativ wenig Schulungsaufwand (bezogen auf Version 4) auf eine neue NAV- Version im CC umzusteigen. Du hast aber auch schon die Möglichkeit eure Firma Abteilungsweise auf den neuen Client umzustellen, und dabei Erfahrungen mit der neuen Umgebung zu sammeln.
Zu den Lizenzkosten kann man nur schwer etwas sagen, ohne eure Firma, das Datenvolumen und die Benutzeranzahl zu kennen.
Es gibt eigentlich drei Möglichkeiten der Lizensierung:
- Mit der Nav-Lizenz: Man kauft pro NAV User eine SQL-User -Lizenz (Standard oder Enterprise) und darf damit einen SQL-Server mit NAV darauf betreiben. Darin enthalten ist auch die Wartung, die es ermöglicht, eine neue SQL-Server- Version zu nutzen, wenn sie für NAV verfügbar ist.
- Man kauft separat Lizenz(en) auf Benutzer, Geräte oder Prozessoren bezogen. Hat den Vorteil, man darf alles mit dem SQL-Server machen was man möchte.
- Wenn die Benutzeranzahl nicht zu groß ist (<70), kann man auch Windows SBS2008 Premium einsetzen. Hier ist ein SQL-Server in der Lizenz erhalten. Man benötigt nur noch entsprechende CALs um auf den Server zuzugreifen
Zur Performance:
Ein vernünftig dimensionierter SQL- Server kann bei gleicher Hardware durchaus schneller sein, als eine native DB. Das hängt vom Datenvolumen ab und den normal ablaufenden Transaktionen ab. Eine aktueller Server ist mit einer nativen Datenbank heute eigentlich unterfordert, da man mit mehr CPU-Kernen und mehr Arbeitsspeicher nichts ausrichten kann. Beim SQL-Server geht das sehr wohl.
Re: Sinnvoller Versionswechsel
9. Februar 2011 15:57
Ein paar Infos mehr wären schon nett.
Geht's da um ein technisches oder ein "richtiges" Update? Von welcher Version auf welche wollt ihr? Welche Hardware besitzt ihr derzeit?
So viel kann man schon mal sagen: SQL-Server und "normale" Reports schließen sich nicht aus; das hängt lediglich von der verwendeten NAV-Version ab. 2009 mit RTC bringt neue Möglichkeiten bei den Reports, im CC bleibt alles wie bisher.
Ob es was umzuprogrammieren gibt, kann man pauschal nicht sagen. Das hängt von den Individualerweiterungen ab.
Zu allen Themen gibt es allerdings schon jede Menge Beiträge - einfach mal suchen.
Ich habe mir sagen lassen: nein. Und Dänen lügen nicht
Geht's da um ein technisches oder ein "richtiges" Update? Von welcher Version auf welche wollt ihr? Welche Hardware besitzt ihr derzeit?
So viel kann man schon mal sagen: SQL-Server und "normale" Reports schließen sich nicht aus; das hängt lediglich von der verwendeten NAV-Version ab. 2009 mit RTC bringt neue Möglichkeiten bei den Reports, im CC bleibt alles wie bisher.
Ob es was umzuprogrammieren gibt, kann man pauschal nicht sagen. Das hängt von den Individualerweiterungen ab.
Zu allen Themen gibt es allerdings schon jede Menge Beiträge - einfach mal suchen.
RiaSavoy hat geschrieben:täusche ich mich, oder ist NAV irgendwie von MSAccess abgekupfert oder umgekehrt???
Ich habe mir sagen lassen: nein. Und Dänen lügen nicht
Re: Sinnvoller Versionswechsel
9. Februar 2011 16:01
Hallo,
willkommen im Forum.
Da stellst Du ja eine ganze Reihe von Fragen.
Nav 2009 hat ja nun auch den RTC und die Service Tier mit einer neuen Architektur.
Die native DB gibt es auch noch, aber ist nicht kompatibel mit Service Tier/RTC. Das geht nur noch mit Classic Client.
Das ganze wird aber in NAV 7 dann auch teilweise abgeschaltet (Forms gibt es dann nicht mehr).
Eine Migration von native auf SQL plus versionswechsel wird eigentlich auch in 2 schritte gemacht. Erst Versionmigration inhaltlich, und dann von nativ auf sql. Oder erst nativ auf SQL und dann inhaltlich upgraden.
Technisch upgraden (DB mit neuem Client öffnen und dann konvertieren (NICHT IM ECHT/PRODUKTIVSYSTEM MACHEN)) wirst du vorher so oder so machen.
Mit dem Client kannst Du dann eine SQL DB auf eurem SQL Server erzeugen und dann das Backup (FBK) eurer nativen DB einspielen.
Server widerverwenden:
Erstmal steht die Frage im Raum: Wie alt ist das Blech?
Dann: Will man den alten Server nicht betriebsbereit lassen im Falle bei Problemen der Migration?
Bei Hardware-Wahl und Konfiguration des SQL Servers empfehle ich dringendst euren Microsoft Dynamics Partner anzusprechen, oder jemand externes bestellen. (Stryk bietet sowas zB an)
SQL Konfiguration ist eine halbe Welt für sich und man kann das nicht durch ein Forum definieren lassen
Performanceunterschiede gibt es auch. Dies hängt aber damit zusammen wie stark modifiziert die Datenbank ist und wie groß sie ist. Auch spielt die Konfiguration und die Hardware drunter eine Rolle.
Die einzige Restriktion die ich bei der nativen DB kenne ist: Es gibt eine maximale Größe soweit ich weiß. Ich glaube 192GB oder 256GB.
SQL Server kann mehr, alles eine Frage wieviel Blech (Hardware) da steht
Die SQL Lizenz kostet auch etwas. Da gibt es entweder das per CPU Sockel oder per User (CAL) Modell zur Abrechnung. Es wird dabei noch zwischen Standard und Enterprise unterschieden. Dies wirkt sich stark im Preis aus, und man muss analysieren, ob man den Mehrnutzen des SQL Servers auch wirklich braucht.
willkommen im Forum.
Da stellst Du ja eine ganze Reihe von Fragen.
Nav 2009 hat ja nun auch den RTC und die Service Tier mit einer neuen Architektur.
Die native DB gibt es auch noch, aber ist nicht kompatibel mit Service Tier/RTC. Das geht nur noch mit Classic Client.
Das ganze wird aber in NAV 7 dann auch teilweise abgeschaltet (Forms gibt es dann nicht mehr).
Eine Migration von native auf SQL plus versionswechsel wird eigentlich auch in 2 schritte gemacht. Erst Versionmigration inhaltlich, und dann von nativ auf sql. Oder erst nativ auf SQL und dann inhaltlich upgraden.
Technisch upgraden (DB mit neuem Client öffnen und dann konvertieren (NICHT IM ECHT/PRODUKTIVSYSTEM MACHEN)) wirst du vorher so oder so machen.
Mit dem Client kannst Du dann eine SQL DB auf eurem SQL Server erzeugen und dann das Backup (FBK) eurer nativen DB einspielen.
Server widerverwenden:
Erstmal steht die Frage im Raum: Wie alt ist das Blech?
Dann: Will man den alten Server nicht betriebsbereit lassen im Falle bei Problemen der Migration?
Bei Hardware-Wahl und Konfiguration des SQL Servers empfehle ich dringendst euren Microsoft Dynamics Partner anzusprechen, oder jemand externes bestellen. (Stryk bietet sowas zB an)
SQL Konfiguration ist eine halbe Welt für sich und man kann das nicht durch ein Forum definieren lassen
Performanceunterschiede gibt es auch. Dies hängt aber damit zusammen wie stark modifiziert die Datenbank ist und wie groß sie ist. Auch spielt die Konfiguration und die Hardware drunter eine Rolle.
Die einzige Restriktion die ich bei der nativen DB kenne ist: Es gibt eine maximale Größe soweit ich weiß. Ich glaube 192GB oder 256GB.
SQL Server kann mehr, alles eine Frage wieviel Blech (Hardware) da steht
Die SQL Lizenz kostet auch etwas. Da gibt es entweder das per CPU Sockel oder per User (CAL) Modell zur Abrechnung. Es wird dabei noch zwischen Standard und Enterprise unterschieden. Dies wirkt sich stark im Preis aus, und man muss analysieren, ob man den Mehrnutzen des SQL Servers auch wirklich braucht.
Re: Sinnvoller Versionswechsel
10. Februar 2011 11:02
Nun, es wurde ja schon alles wichtige angesprochen, aber hier noch kurz mein Kommentar:
"Natives" NAV ist tot. Punkt. Ende. D.h. eine Interimslösung auf dem proprietären C/SIDE Server ist Zeit- & Geldverschwendung - wenn schon ein Wechsel ansteht, dann sollte man dabei ausschließlich den SQL Server in Betracht ziehen.
Die "alte" Hardware ist in der Regel nicht SQL Server tauglich, da beide System sehr unterschiedliche Anforderungen haben. Aber wie schon gesagt wurde, das "Blech" müsste man mal abklopfen ...
Die Lizenzkosten sind natürlich höher als vorher mit C/SIDE Server - ein "totes Pferd" sollte ja auch billiger sein
- aber eine NAV/SQL Server Lösung ist letztlich auch nicht teurer als vergleichbare Konkurrenzprodukte ... Und man bekommt ja auch was für sein Geld, also Möglichkeiten die mit der alten Büchse undenkbar wären!
Performance Unterschiede gibt es sehr wohl! Im guten wie im schlechten Sinne. Das ist aber ein Thema das man sehr ausführlich erörten müsste; aber in Kürze: SQL Server ist ein Hochleistungssystem, das in Sachen Geschwindigkeit, Skalierbarkeit und Möglichkeitem dem nativen Server weit überlegen ist. Leider nutzt die NAV Applikation diese Möglichkeiten nicht bzw. nicht richtig; d.h. das Zusammenspiel zwischen NAV & SQL Server ist nicht optimal, daher kann es zu Problemen kommen. Die kann man aber i.d.R. beseitigen oder umgehen; und auch "out-of-the-box" wird es mit jedem NAV Release besser.
Wer sich heute für Dynamics NAV entscheidet, der entscheidet sich damit zwangsläufig auch für SQL Server.
"Natives" NAV ist tot. Punkt. Ende. D.h. eine Interimslösung auf dem proprietären C/SIDE Server ist Zeit- & Geldverschwendung - wenn schon ein Wechsel ansteht, dann sollte man dabei ausschließlich den SQL Server in Betracht ziehen.
Die "alte" Hardware ist in der Regel nicht SQL Server tauglich, da beide System sehr unterschiedliche Anforderungen haben. Aber wie schon gesagt wurde, das "Blech" müsste man mal abklopfen ...
Die Lizenzkosten sind natürlich höher als vorher mit C/SIDE Server - ein "totes Pferd" sollte ja auch billiger sein
- aber eine NAV/SQL Server Lösung ist letztlich auch nicht teurer als vergleichbare Konkurrenzprodukte ... Und man bekommt ja auch was für sein Geld, also Möglichkeiten die mit der alten Büchse undenkbar wären!Performance Unterschiede gibt es sehr wohl! Im guten wie im schlechten Sinne. Das ist aber ein Thema das man sehr ausführlich erörten müsste; aber in Kürze: SQL Server ist ein Hochleistungssystem, das in Sachen Geschwindigkeit, Skalierbarkeit und Möglichkeitem dem nativen Server weit überlegen ist. Leider nutzt die NAV Applikation diese Möglichkeiten nicht bzw. nicht richtig; d.h. das Zusammenspiel zwischen NAV & SQL Server ist nicht optimal, daher kann es zu Problemen kommen. Die kann man aber i.d.R. beseitigen oder umgehen; und auch "out-of-the-box" wird es mit jedem NAV Release besser.
Wer sich heute für Dynamics NAV entscheidet, der entscheidet sich damit zwangsläufig auch für SQL Server.
Re: Sinnvoller Versionswechsel
10. Februar 2011 14:59
stryk hat geschrieben:Nun, es wurde ja schon alles wichtige angesprochen, aber hier noch kurz mein Kommentar:
"Natives" NAV ist tot. Punkt. Ende. D.h. eine Interimslösung auf dem proprietären C/SIDE Server ist Zeit- & Geldverschwendung - wenn schon ein Wechsel ansteht, dann sollte man dabei ausschließlich den SQL Server in Betracht ziehen.
[...]
Die Lizenzkosten sind natürlich höher als vorher mit C/SIDE Server - ein "totes Pferd" sollte ja auch billiger sein
Das "tote Pferd" wird dafür aber noch reichlich oft geritten!
Mfg,
winfy
Re: Sinnvoller Versionswechsel
10. Februar 2011 15:14
<off_topic>
Eine Weisheit der Dakota-Indianer sagt:
"Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab."
Doch im Berufsleben versuchen wir oft eine ganze Menge anderer Strategien, wie wir in dieser Situation handeln . . .
1. Wir besorgen eine stärkere Peitsche.
2. Wir wechseln die Reiter.
3. Wir sagen: "So haben wir das Pferd doch immer geritten."
4. Wir gründen einen Arbeitskreis, um das Pferd zu analysieren.
5.Wir besuchen andere Orte, um zu sehen, wie man dort tote Pferde reitet.
6. Wir erhöhen die Qualitätsstandards für den Beritt toter Pferde.
7.Wir bilden eine Task Force, um das tote Pferd wiederzubeleben.
8. Wir schieben eine Trainingseinheit ein, um besser reiten zu lernen.
9. Wir stellen Vergleiche unterschiedlich toter Pferde an.
10. Wir ändern die Kriterien, die besagen, ob ein Pferd tot ist.
11. Wir kaufen Leute von außerhalb ein, um das tote Pferd zu reiten
12. Wir schirren mehrere tote Pferde zusammen an, damit sie schneller werden.
13. Wir erklären "Kein Pferd kann so tot sein, dass man es nicht noch schlagen könnte."
14. Wir machen zusätzliche Mittel locker, um die Leistung des Pferdes zu erhöhen.
15. Wir machen eine Studie, um zu sehen, ob es billigere Berater gibt.
16. Wir kaufen etwas zu, das tote Pferde schneller laufen lässt.
17. Wir erklären, dass unser Pferd "besser, schneller und billiger" tot ist.
18. Wir bilden einen Qualitätszirkel, um eine Verwendung für tote Pferde zu finden.
19. Wir überarbeiten die Leistungsbedingungen für Pferde.
20. Wir richten einen unabhängige Kostenstelle für tote Pferde ein.
</off_topic>
Eine Weisheit der Dakota-Indianer sagt:
"Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab."
Doch im Berufsleben versuchen wir oft eine ganze Menge anderer Strategien, wie wir in dieser Situation handeln . . .
1. Wir besorgen eine stärkere Peitsche.
2. Wir wechseln die Reiter.
3. Wir sagen: "So haben wir das Pferd doch immer geritten."
4. Wir gründen einen Arbeitskreis, um das Pferd zu analysieren.
5.Wir besuchen andere Orte, um zu sehen, wie man dort tote Pferde reitet.
6. Wir erhöhen die Qualitätsstandards für den Beritt toter Pferde.
7.Wir bilden eine Task Force, um das tote Pferd wiederzubeleben.
8. Wir schieben eine Trainingseinheit ein, um besser reiten zu lernen.
9. Wir stellen Vergleiche unterschiedlich toter Pferde an.
10. Wir ändern die Kriterien, die besagen, ob ein Pferd tot ist.
11. Wir kaufen Leute von außerhalb ein, um das tote Pferd zu reiten
12. Wir schirren mehrere tote Pferde zusammen an, damit sie schneller werden.
13. Wir erklären "Kein Pferd kann so tot sein, dass man es nicht noch schlagen könnte."
14. Wir machen zusätzliche Mittel locker, um die Leistung des Pferdes zu erhöhen.
15. Wir machen eine Studie, um zu sehen, ob es billigere Berater gibt.
16. Wir kaufen etwas zu, das tote Pferde schneller laufen lässt.
17. Wir erklären, dass unser Pferd "besser, schneller und billiger" tot ist.
18. Wir bilden einen Qualitätszirkel, um eine Verwendung für tote Pferde zu finden.
19. Wir überarbeiten die Leistungsbedingungen für Pferde.
20. Wir richten einen unabhängige Kostenstelle für tote Pferde ein.
</off_topic>
Re: Sinnvoller Versionswechsel
11. Februar 2011 13:43
Super 
diesen off-topic muss ich mir merken bzw. kopieren.
diesen off-topic muss ich mir merken bzw. kopieren.
Re: Sinnvoller Versionswechsel
11. Februar 2011 17:49
JRenz hat geschrieben:Super
diesen off-topic muss ich mir merken bzw. kopieren.
Leicht variiert auch hier.