[Gelöst] Erfahrung mit Nav 3.6 auf SQL DB

Morgen,

wir arbeiten an einem Standort mit einem techn. Updat auf Nav 3.6.
Diese wurde aus einer 2.6er-Version konvertiert.

Wir haben über eine Webapplication eine Verbindung zwischen einem Barcodescanner zu Navision hergestellt!
Leider ist die C/ODBC-Schnittstelle zu langsam, dass sich unsere Anwender weigern die Wareneingänge einzuscannen. Ursache ist wohl eine Plausibilitätsprüfung um festzustellen, ob ein bestimmter Artikel in einer bestimmten Bestellung vorhanden ist.

Jetzt war die Überlegung, Navision auf SQL 2005 aufzusetzen.
Meine Frage nun, bringt das was????

Auch hier habe ich viel über das Theme Navision und SQL gelesen, aber meine Frage bleibt einfach offen.

Gruß
Winkelsbr

Zuletzt geändert von winkelsbr am 2. Juli 2008 12:49, insgesamt 1-mal geändert.

Ein Wagen mit blockierten Bremsen wird auch mit einer neuen Zugmaschine nicht auffällig viel schneller unterwegs sein. Die Bremsen sind halt immer noch blockiert. Möglicherweise wird er sogar von der Straße abkommen.

Selbst eine techisch hochgezogene 2.x ist von der Applikation her eine in keinster Weise auf SQL abgestimmte Applikation. Und leider ist es ohne sich einen genaueren Überblick über die Applikation selbst und die Landschaft zu verschaffen kaum möglich hier eine passende Aussage zu treffen.

Möglicherweise könnt ihr die Daten zur Prüfung auf einen SQL Server (Express) exportieren, um den Scanvorgang zu beschleunigen. Vielleicht ist aber auch die Applikation ansich nicht so performant programmiert, so dass man hier in einem ersten Schritt noch etwas heraus holen kann.

Du könntest die Umstände und die Umgebung etwas näher definieren (Server, Datenbankgröße, Plattenkonfiguration, welche Tabellen werden geprüft etc.). Dann kann man ggf. mehr dazu sagen.

Hallo SilverX,

Die Navision Datenbank läuft unter Windows 2003 R2 auf einem HP DL 360 G5
und hat eine 2 GB-Anbindung ins Firmennetz.
Die Datenbankgröße ist gerade mal 4 GB groß.

Ansicht läuft Navision problemlos, soweit man das von der Native-DB sagen kann.

Die Web-Applikation als solches ist auch nicht das Problem.

Hier mal kurz die Beschreibung zum eigentlichen Workflow:
1. Der Anwender "loggt" sich mittels Barcode ein. Diese Daten haben nichts mit Navision zu tun und liegen in einer XML-Datei
2. Der Anwender ruft die Bestellung auf (erster Zugriff auf Navision Einkaufskopf). Hier existiert vorab ein Filter, dass er nur die Bestellungen aus den letzten 1 1/2 Jahren aufruft.
3. Artikelnummer wird eingescannt. Hier wird in den Einkaufszeilen geprüft, ob der Artikel auch in der Bestellung vorhanden ist (zweiter Zugriff auf Navision)
4. Der Anwender gibt die Menge des Artikel ein. Nachdem alle Positionen erfasst wurden, schließt der Mitarbeiter die Form der Applikation, werden die erfassten Daten in einer separaten Tabelle in Navision geschrieben(dritter Zugriff).

Das Problem liegt an der ODBC-Schnittstelle. Es ist ja bekannt, dass diese nicht sehr perfomant ist. Deshalb die Überlegung mit SQL.

Gruß
Wolfgang

Hallo winkelsbr,

da ihr nur ein technisches Update durchgeführt habt, sprechen wir funktional immernoch von 2.6. D.h. da selbst ein vollständiges 3.6 Lichtjahre vom SQL2005 entfernt ist, solltet ihr keine Zeit für etwas aufwenden, was sicherlich schon diverse ohne Erfolg probiert haben.(Kommt vielleicht bekannt vor?)
Erst ab 4.0 Standard sind viele Codeelemente für den 2005 ausgelegt.
Wir haben gerade ein 3.7 Upgrade (4.0) mit Umzug auf 2005 mit einigen SQL Gurus hinter uns und es war kein Vergnügen.

Gruß
defiant701

Hallo Definat701,

das habe ich mir ja auch schon gedacht!
Aber manchmal kommen neue Besen, die meinen besser kehren zu können als andere.
Mir persönlich wäre ein komplett Umstieg lwesentlich lieber als mich mit dem bestehenden rumzuärgern.

Auf jeden Fall auch allen vielen Dank.