NAV Datenexport in andere SQL-DB

Hallo zusammen,

kann mir jemand einen Tip geben wie ich aus NAV heraus direkt in Tabellen einer anderen SQL-DB (nicht NAV) schreiben kann?
Irgendwie stehe ich gerade auf dem Schlauch.

Vielen Dank für eure Hilfe.

In diesem Thema ist ein Link zu Waldo's Blog.

Hallo,

einen Versuch ist bestimmt die SQL - Replikation der entsprechenden Tabellen wert.

Grüße

Sascha

Ich behaupte mal, wenn euer NAV auch auf SQL läuft, ist die einfachste Variante Views zu nutzen. Dazu den anderen SQL-Server als Linked Server (in deutsch: Verbindungsserver) auf dem NAV-SQL-Server hinzufügen (und die Anmeldungen mappen). Danach können für diesen verknüpften Server auch Views erstellt werden. Wenn die View einfach nur ein SELECT-Statement (also ohne JOINs oder UNION SELECTs etc.) enthält, kann man auch die Tabelle aus NAV beschreiben. Eventuell muss dafür noch der MSSDTC-Dienst konfiguriert werden (DTC-Netzwerkzugriff erlauben).

Dazu muss natürlich noch die passende Tabelle in NAV erzeugt werden, insofern könnte es die teuerste Variante sein, falls zusätzliche Tabellen gekauft werden müssen. Allerdings ist es auch die komfortabelste, da dann die View wie eine NAV-Tabelle gelesen und geschrieben werden kann.

Da es wenn möglich immer besser ist die Daten durch das System dem die Tabelle gehört schreiben zu lassen, würde ich wenn möglich die Logik umdrehen und die Server genau andersherum verknüpfen.

Was soll denn damit erreicht werden? Einfach nur eine Kopie, damit man da Datenanlyse betreibt, oder Daten in ein anderes System bringen? Falls ja, dann würde ich das ganz ohne NAV lösen, nur mit dem SQL-Server. In den SQL-Tabellen kann man Trigger anlegen und mittels SQLBroker asynchron verarbeiten. Ob das dann in eine andere SQL-DB, Webservice oder sonst wohin geschrieben wird bleibt dann dem Entwickler überlassen. Ohne SQL-Broker aber bitte nicht, sonst blockiert ein lange laufender (synchroner) SQL-Trigger die weitere Verarbeitung der Tabelle und damit NAV.

Volker

Man vergesse nicht die Dokumentation solcher Änderungen, die nicht im NAV zu sehen sind.
Trigger auf Tabellen zu programmieren, zu dokumentieren und zu warten ist das komplexeste aller Vorschläge.
Keep it simple!

Hi Jan,

da magst Du recht haben, aber bis jetzt hat er nicht gesagt wo z. B. der Zielserver steht. Und wenn NAV lange braucht um z. B. Daten über einen Webservice (und WAN) zu übertragen ist das für die Usability bestimmt nicht gut. Kleiner Nebeneffekt am Rande ist, dass man u. U. nicht alles in NAV lizenzieren muss und nicht immer auf einen Partner angewiesen ist, der Zugriff auf den C/AL-Code hat. Damit könnte es unterm Strich deutlich billiger sein.

Wichtig ist aber mit Sicherheit auf die notwendige SQL-Sicherung hinzuweisen. Die NAV-Sicherung sichert solche Sachen nicht mit.

Volker

Der TE ist Partner ;)

Davon ab: Sollte der Kunde das Application Builder Granule haben, dann kann er eh den C/AL Code selbst bearbeiten.

Aber der Partner hat auch eine Interesse das ganze wartungsarm zu halten. Und so viele NAVler mit tiefen SQL-Kenntnissen gibt es nicht, die das dann supporten könnten. Also wirds wohl eine C/AL Lösung sein.

Eine weitere Möglichkeit, wäre per ADO direkt in die betreffenden Tabellen zu schreiben.

Allerdings finde ich die Variante mit dem View eleganter.

Also ADO ist doch eigentlich tot, gerade wenn man an RTC basierend auf .NET denkt. Was die SQL-Kenntnisse anbelangt, so muß eigentlich jeder Partner min einen SQL-kompetenten Mitarbeiter haben und aufgrund der zukünftigen Focusierung nur noch auf SQL-Server ist das in meinen Augen sogar unumgänglich. Auch glaube ich, dass in Firmen eher SQL-Kompetenz vorhnden ist als C/AL. Wie hoch der Anteil an Kunden ist, die das Application Builder Granule haben/sich leisten können weiß ich nicht, aber ich kann mir nicht vorstellen, dass dies sehr verbreitet ist. Wenn man dann noch an die Probleme der 32-bit Komponenten auf 64-bit-Servern denkt ist eine reine SQL-Lösung bestimmt die sauberste. Und wie gesagt wissen wir immer noch nicht wie der Übertragungsweg zwischen den Datenbanken aussieht.

Volker

Also ADO ist doch eigentlich tot, gerade wenn man an RTC basierend auf .NET denkt. Was die SQL-Kenntnisse anbelangt, so muß eigentlich jeder Partner min einen SQL-kompetenten Mitarbeiter haben und aufgrund der zukünftigen Focusierung nur noch auf SQL-Server ist das in meinen Augen sogar unumgänglich. Auch glaube ich, dass in Firmen eher SQL-Kompetenz vorhnden ist als C/AL. Wie hoch der Anteil an Kunden ist, die das Application Builder Granule haben/sich leisten können weiß ich nicht, aber ich kann mir nicht vorstellen, dass dies sehr verbreitet ist. Wenn man dann noch an die Probleme der 32-bit Komponenten auf 64-bit-Servern denkt ist eine reine SQL-Lösung bestimmt die sauberste. Und wie gesagt wissen wir immer noch nicht wie der Übertragungsweg zwischen den Datenbanken aussieht.

Volker

Sorry,

aber glaubst Du auch noch an den Weihnachtsmann? Ich komme von einem Partner und ich weiß wie es da aussieht.
Kein NAV Partner bevorzugt SQL-Lösungen, da sie kein Geld einbringen (Wartung), hohe Supportskosten haben, Fachpersonal benötigen. Wozu machen?
Je qualifizierter die Mitarbeiter, desto teurer sind sie.

Kein NAV Partner bevorzugt SQL-Lösungen, da sie kein Geld einbringen (Wartung), hohe Supportskosten haben, Fachpersonal benötigen. Wozu machen?

Verstehe ich nicht. Ich berechne das genauso wie andere NAV-Dienstleistungen auch. Warum denn auch nicht? Wenn ich eine einfach Lösung in NAV stricke erhöht sich doch die Wartung auch nicht, es sei denn es werden neue Objekte benötigt, aber das sind ja keine Beträge.

Es stimmt zwar, was du berichtest, nämlich das viele Partner die Kosten in Weiterbildung nicht investieren wollen, aber lohnen tut es sich allemal, da man auch neue Dienstleistungen verkaufen kann. Ich behaupte auch, dass die View-Lösung eine der wartungsärmsten ist. Wenn die Verbindung zwischen den Servern steht, ist der Rest reine NAV-Programmierung. Und grundsätzlich kann die Einrichtung der "Linked Server" auch vom Kunden verändert werden, was einigen Kunden entgegenkommt.

Schließlich und endlich: es ist nicht zu ändern. In Zukunft wird es für einen Partner nicht mehr reichen nur NAV-KnowHow zu haben. Bei AX kommt ja zum 1. Mai die Notwendigkeit der Sharepoint-Kompetenz für Partner dazu. Mit NAV 2013 wird es für die NAV-Sparte wahrscheinlich auch kommen.

P.S.: Tipp: manchmal lassen sich sehr komplexe Reports durch eine geschickt angelegte View sehr stark vereinfachen. Dort kann man nämlich JOINs verwenden, die in NAV bekanntlich regelmäßig nur durch aufwändige Programmierung zu ersetzen sind.

P.S.: Tipp: manchmal lassen sich sehr komplexe Reports durch eine geschickt angelegte View sehr stark vereinfachen. Dort kann man nämlich JOINs verwenden, die in NAV bekanntlich regelmäßig nur durch aufwändige Programmierung zu ersetzen sind.

Wobei hier ja auf Besserung mit NAV2013 zu hoffen ist