Neuanschaffung NAV

Hallo Community,
wir setzten zur Zeit noch Navision 3.7 A als ERP System ein. Nach langem Überlegen haben wir uns entschlossen unsere ERP Lösung auf die aktuellste Version up zu daten (schrfeibt man das so???) Wir haben bei unserem Systemhaus angefragt und auch andere Angebote eingeholt.
Wir setzten zur Zeit keinen SQL-Server ein. Unsere Datenbank läuft als Client only. Jetzt die Frage bei einem Angebot bietet uns ein Systemhaus NAV auf Grundlage des SQL Servers an. Alle anderen würden die native Db beibehalten. Welche Vorteile / Nachteile hat eine Umstellung von unserer nativen Db auf eine SQL-Server basierte Db?
Da ich Quereinsteiger in Sachen NAV bin und relativ wenig Ahnung habe, wende ich mich an Euch. Ich bedanke mich im voraus für Eure Hilfe

Hallo Jörg,

der SQL-Server hat den Vorteil, dass er auch mit dem neuen Role Tailored Client(RTC) von NAV 2009 zusammenarbeitet, d.h. für den RTC ist zwingend der SQL-Server notwendig.

Meinst du mit "Client Only" das die Datenbank nur an einem PC genutzt wird (sprich Einzelpatzsystem), und nur ein Benutzer z.Zt. darauf zugreift?

Falls ja, und das so beibehalten werden soll, scheint mir der SQL-Server ein wenig "Overdosed".
Man kann aber mit NAV 2009 auch über SQL-Express arbeiten. Den man lokal installiert, und man arbeitet dann auf der SQL-Datenbank. Für ein Einzelplatzsystem ist das aber normalerweise nicht notwendig. Es sei denn man möchte die neuen Features von NAV2009 nutzen (z.B. RTC) oder das Reporting des SQL-Servers.

Gruß, Fiddi

Hallo fiddi, danke für die schnelle Antwort.

ich bin schon ein depp unsere Db läuft natürlich mittels Navision Server dienst auf nem Server, auf den etwa 35 User zugreifen. Also Installation auf Server aber ohne SQL.
Ich hab das mit meiner Testinstallation verwechselt... Newbie halt..
Was genau macht dieser RTC? Ich bin für alle infos dankbar da ich meiner GL auch Report erstatten muss, was die Häuser so alles anbieten und wozu das ganze gut is.
Wie gesagt, ich soll jetzt etwas dazu sagen, ob es sich lohnt das Geld für den SQL nebst Zugriffslizensen auszugeben.
Des weiteren haben wir von Office 2000 bis 07 alles im Einsatz. Das gros läuft auf Office 2003. Welche Office Version setzt NAV 2009 voraus bzw. bei welcher gibts die wenigsten Probleme...
Nochmals Danke für die Antworten.

Vile Grüße aus dem tief verscheniten Hof

Dann sieht die Sache schon ganz anders aus.
Wenn du mit 35 Benutzern an der DB arbeitest (die benutze DB- Größe wäre noch interessant, unter 'Datei/Datenbank/Informationen'), dann macht es unter heutigen Gesichtspunkten sicherlich Sinn auf den SQL-Server umzusteigen, da man davon ausgehen kann, das der Trend in diese Richtung geht.

Du solltest aber auch bedenken, das du evtl. einen neuen leistungsfähigeren Server anschaffen musst, damit er die Anforderungen erfüllen kann. Dies gilt allerdings auch für die native DB, wenn ihr den Server solange habt, wie die NAV-DB. Gehe davon aus, das die NAV-DB beim Update auf um einiges größer wird.

Der RTC ist eine neue Art von Client, die eine einfachere Bedienung des Clients ermöglichen soll.

Was in NAV 2009 an der Oberfläche alles neu ist, kannst du dir hier anschauen.

Gruß, Fiddi

Die Antwort erscheint mir nicht ganz einfach und doch wieder sehr einfach ...

Meines Wissens wird die Native Datenbank doch jetzt sowieso endgültig abgekündigt, so sich
die Frage gar nicht mehr stellt. Das basiert aber auch wieder auf Informationen, die letzlich
von meinem System Haus kommen.

Als wir 2006 auf den SQL Server umgestellt haben, war das mit viel "Schmerz" verbunden, auch
weil die meisten Systemhäuser damals noch keine wirkliche Erfahrung hatten. Mit zusätzlicher
externer Hilfe haben wir aber heute eine technische Plattform auf Basis des MS SQL 2005 die
ich nicht mehr missen möchte. Auch denke ich, dass alle Systemhäuser inzwischen wesentlich
mehr Erfahrung mit den SQL Implementierungen haben.

Allerdings muss auch klar sein, dass man unter Navision nach wie vor nicht in SQL programmiert,
und Navision alle Abfragen quasi für den SQL Server übersetzen muss, und diese Übersetzungen
(kann man sich bei entsprechenden Kenntnissen unter dem Profiler des SQL Servers anschauen)
sind gelinde gesagt suboptimal. Aus diesen Gründen haben wir hier (83 User) in 2008 auch ziemlich
großes Geschütz aufgefahren und arbeiten heute unter W2003 64 Bite, SQL 2005 64 Bit, 8 Core
Server mit 32 GB RAM und EMC Storage unter der technischen Version 5.1
Diese und nur diese Kombination hat damals in unseren ausführlichen Tests eine vernünftige
Performance ergeben, wobei vor allem das viele RAM, der Write Cache des Storage und die VSIFTs
der 5er Version den Push ergeben haben. Konkret heißt das, dass wir die durchschnittliche Zeit
für das Buchen von 1 Auftrags-Position von 430 auf 210 ms verbessern konnten.
Aber auch aus Sicherheits-Erwägungen möchte ich nicht mehr auf den SQL Server verzichten. Während
wir anfangs nur 5 minütliche Transaktions-Sicherungen gemacht haben, verwenden wir inzwischen auch
das asynchrone Mirroring des SQL 2005, so dass wir quasi ein permanentes transaktionsorientiertes Backup
fahren.

Den RTC als Grund für den Umstieg auf SQL zu sehen, halte ich für verfrüht. Da sind doch noch
viele Fragen offen, und vor allem kommt dann ja noch das Thema Application Server hinzu, also
noch mehr Hardware Infrastruktur.

Wie gesagt - eine schwierige Frage. Ich habe hier ein Test-System mit einer 4 Kern RX 300 und
18 GB RAM, Software gleich, also 64 Bit SQL 2005 und Nav 5.1. Das System läuft auf einem JBOD
mit 12 per RAID 12 gespiegelten 15k SAS Platten über 8port SFF8088 (also 24 GBit) an einen LSI
Controller angebunden.
Das läuft wunderbar flüssig, und hat alles was man bei 35 usern brauchen sollte, und ist auch nicht so
teuer, aber "to be honest": Ich kann nicht sagen wie gut das in einer x-User Echtumgebung laufen
würde, und da liegt immer der Kasus Knaktus.

So what: Setzt Euch damit auseinander, ihr habt mittelfristig eh keine andere Perspektive!

Pidi

Allerdings muss auch klar sein, dass man unter Navision nach wie vor nicht in SQL programmiert,
und Navision alle Abfragen quasi für den SQL Server übersetzen muss, und diese Übersetzungen
(kann man sich bei entsprechenden Kenntnissen unter dem Profiler des SQL Servers anschauen)
sind gelinde gesagt suboptimal.

Ich würde mal behaupten, dass man Sie an solche Abfragen mit zunehmendem Einsatz von LINQ und Co. gewöhnen muss.

Volker

Wer um die Mächtigkeit von SQL Abfragen weiß, wird sich darüber auch einen Wolf freuen,
und spätestens nach einigen Joins merken, dass die Navision Methode nicht unbedingt immer
die einfachere ist. Und wenn es dann auch noch via LINQ funktioniert - wunderbar!

Nun darf man aber auch nicht übersehen, dass der besondere Charme von Navision teils darin
liegt, dass man auf einer Form filtern kann, woraus dann wohl später die Programmierung mit
ihren einschlägigen Befehlen entstanden ist ... und da wir kaum den Anwender mit SQL statements
konfrontieren wollen ...

Ich müßte außerdem ganz gewaltig etwas verpasst haben, wenn unter Navision außer selbst
gefummelten ADO Klamotten, die ich schon fleißig für den Zugriff auf andere Datenbanken
einsetze, irgendetwas in dieser Richtung vorhanden wäre. Werde mal die Forum-Suche bemühen.

Außerdem fällt mir gerade uaf, dass dies hier langsam am Thema des Threads vorbei geht, ausser
dass es bestätigt, dass an SQL kein Weg vorbei führt. Also: SQL = JA!

Pidi

nicht vergessen sollte man auch, dass bei der nativen Datenbank mit 256 GByte Schluss ist.
Wenn auch nur eine geringe Wahrscheinlichkeit besteht, dass in den nächsten Jahren diese
Grenze überschritten wird, währe das ein klares Argument für SQL-Server.

Gruß Torsten