engelhuber.de //blog

Gehirnfürze aus der Sicht eines Nerds

Dynamics NAV: TableType ExternalSQL als Alternative zu LinkedObject

| 1 Kommentar

Ich bin nun seit ein paar Monaten endlich in dem Genuss mal mit einer neuer Microsoft Dynamics NAV Version (2018) rum zu spielen. Neben neuen Objekt Typen gibt es natürlich auch zahlreiche neue Properties, wie zum Beispiel das Property „TableType“ auf der Tabelle.

Von einigen Jahren beschrieb ich hier wie man mit Hilfe des Property LinkedObject auf eine SQL View zugreifen kann und somit Daten aus anderen Quellen anzeigen lassen kann. Dieses Property gibt es nach wie vor, jedoch habe ich in NAV 2018 nun versucht die gleiche Anforderung wie damals zu realisieren, was aber in einem Fehler endete.

Das Problem hieran war, dass meine View Daten eines anderen SQL Servers über einen Verbindungsserver anzeigt. Leider erhielt ich bei meinen Versuchen jedes mal den folgenden Fehler:

„Der folgende SQL-Fehler war nicht erwartet: Der Vorgang konnte nicht ausgeführt werden, da der OLE DB-Anbieter „SQLNCL11″ für den Verbindungsserver XXX keine verteilte Transaktion beginnen konnte…“

Warum hier überhaupt eine Transaktion gestartet wurde ist mir unklar, da ich nur Daten anzeigen lasse. Ich habe einige Einstellungen ausprobiert und mit Berechtigungen rumhantiert, aber ich habe es nicht ans Laufen gebracht. Views die nur Daten des „eigenen“ Servers anzeigen funktionierten allerdings.

TableType = ExternalSQL ist die Lösung

Durch Zufall bin ich bei meiner Recherche dann auf dieses für mich neue Property TableType auf der Tabelle gestoßen. Hiermit ist es möglich auf Tabellen oder Views von anderen SQL Servern zuzugreifen und nicht nur auf Views die in der NAV DB angelegt wurden. Allerdings ist hierzu auch etwas Code notwendig, aber dazu später mehr.

Wählt man hier ExternalSQL, erhält man zwei weitere Properties: ExternalName & ExternalSchema. In ExternalName trägt man die Tabelle/View ein auf die man zugreifen möchte und in ExternalSchema das jeweilige Schema des Objektes. Im Gegensatz zu LinkedObject, ist es hier egal wie die Tabelle/View heißt, sie muss nicht genau so heißen wie das NAV Objekt.

Die Spalten eurer Tabelle sollten so heißen und den gleichen Datentyp haben wie die der externen Tabelle/View. Weichen die Namen ab, so kann der korrekte Name im Feld Property ExternalName hinterlegt werden.

In der dazugehörigen Page sind keine besonderen Properties notwendig, lediglich etwas Code um die Verbindung zum Server aufzubauen.
Im OnInit Trigger der Page muss folgender Code platziert werden:

IF HASTABLECONNECTION(TABLECONNECTIONTYPE::ExternalSQL, ‚MyTableConnection1‘) THEN
UNREGISTERTABLECONNECTION(TABLECONNECTIONTYPE::ExternalSQL,’MyTableConnection1′);
REGISTERTABLECONNECTION(TABLECONNECTIONTYPE::ExternalSQL, ‚MyTableConnection1‘, ‚Server=SERVERNAME/IP;Database=DATENBANK;User ID=BENUTZER;Password=PASSWORT‘);
SETDEFAULTTABLECONNECTION(TABLECONNECTIONTYPE::ExternalSQL,’MyTableConnection1′);

Alternativ kann hier auch mit der Windows Anmeldung gearbeitet werden:

REGISTERTABLECONNECTION(TABLECONNECTIONTYPE::ExternalSQL, ‚MyTableConnection1‘, ‚Server=SERVERNAME/IP;Database=DATENBANK;Integrated Security=SSPI‘);

Nun sollte der Zugriff auf die externen Daten bereits möglich sein. In meinem Fall erhielt ich allerdings den gleichen Fehler wie mit LinkedObject. Da wir aber – wie oben erwähnt – mit ExternalSQL auf Tabellen/Views von externen SQL Servern zugreifen können, muss die View nicht zwangsweise auf dem NAV Server liegen. Also habe ich sie auf dem Server platziert der auch die Daten bereithält und gehe somit nicht mehr den Umweg über den Verbindungsserver. Und siehe da, es funktioniert 😀

Ändern der Daten ist im Übrigen hierüber auch möglich!

Autor: Engelhuber

Wenn dir der Post hilfreich war bzw. er dir gefallen hat, würde ich mich über ein Kommentar freuen. Natürlich ist auch negative Kritik gerne gesehen ;)

Ein Kommentar

  1. Pingback: SQL View in NAV anzeigen - engelhuber.de //blogengelhuber.de //blog

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.