"CODE" im SQL-Server

Guten Morgen,

kann mir einer sagen wo NAV speichert, dass es sich bei einer Tabellenspalte um ein Code-Feld handelt? Im SQL-Server sind das schließlich alles nur Varchar-Felder. Irgendwo muss aber NAV ja die Info herbekommen, dass es ein Codefeld und kein Textfeld ist.

Volker

Hi,
prinzipiell sollte das wohl aus der Object-Tabelle kommen.
Wenn du Zugriff auf diese Informationen brauchst kannst du allerdings auch die Field-Tabelle verwenden.

Im SQL-Server sind das schließlich alles nur Varchar-Felder

Das ist der default, es kann aber auch Integer, Variant oder Biginteger sein, je nachdem was in der "SQL Data Type"- Property des CODE- Feldes hinterlegt ist.

Gruß, Fiddi

Also in der Tabelle Object im SQL-Server stehen nur die Tabellen drin.
Eine Tabelle Field gibt es bei mir im SQL-Server in der NAV-DB nicht.

Wo im SQL-Server wird denn "SQL Data Type"- Property des CODE- Feldes im SQL-Server gespeichert?

Kurze Erklärung, warum mich das interessiert:
In der Tabelle "Record Links" werden Links und Notizen gespeichert. Ich will nun zu einem bestimmten Record (z. B. Kunde XY) alle Links und Notizen auslesen. Aber eben nicht über CC oder RTC, sondern direkt aus der Tabelle. In der Spalte "Record ID" steht Tabelle, Datentyp des Primärschlüssels, und der Wert des Primärschlüssels für den Datensatz drin. Ermittlung der Tabelle ist ja kein Problem, der Wert des Primärschlüssels ist auch bekannt, nur der Datentyp ist nicht bekannt. Dieser muss aber ja irgendwo hinterlegt sein und dann sollte man den ja auslesen können.

Volker

Wo im SQL-Server wird denn "SQL Data Type"- Property des CODE- Feldes im SQL-Server gespeichert?

vermutlich in der Tabelle Object

Gruß,fiddi

Wie gesagt in der Tabelle Object in der NAV-DB stehen nur die Tabellen, nicht aber deren Spalten. Die Spalten und deren (SQL-)Datentypen kann man aus den Systemtabellen (syscolumns und systypes) auslesen.

Nur erhält man dort z. B. für "No_" der Tabelle Sales Header als Datentyp Varchar(20). Nur wissen wir aber alle dass das kein Textfeld ist, sondern ein Code-Feld. Aber woher weiß NAV das?

Volker

Frage am Rande: Warum verwendest du nicht einfach Webservices und lässt dir darüber die gewünschten Daten liefern?

Wie gesagt in der Tabelle Object in der NAV-DB stehen nur die Tabellen, nicht aber deren Spalten. Die Spalten und deren (SQL-)Datentypen kann man aus den Systemtabellen (syscolumns und systypes) auslesen.

In einem Eintrag in der Tabelle Object steht die komplette Definition des Objekts: Code, Properties, Objekt- Text,...). Die Tabelle Field ist eine virtuelle Tabelle, die auf die Object- Tabelle schaut, um sich die Ergebnisse zu holen.

Gruß, Fiddi

Frage am Rande: Warum verwendest du nicht einfach Webservices und lässt dir darüber die gewünschten Daten liefern?

1. Geschwindigkeit -> Direkt SQL ist schneller als erst über NST
2. Stabilität -> Falls NST nicht verfügbar funktioniert das trotzdem

Volker

In einem Eintrag in der Tabelle Object steht die komplette Definition des Objekts: Code, Properties, Objekt- Text,...). Die Tabelle Field ist eine virtuelle Tabelle, die auf die Object- Tabelle schaut, um sich die Ergebnisse zu holen.
Gruß, Fiddi

Kann ich nur so bestätigen!

Wenn du die Daten ausliest, warum musst du dann zwischen Code und Text unterscheiden? Die Unterscheidung sollte doch erst beim einfügen per SQL in die Navision-Tabellen wichtig werden (bitte immer über UPPER!).

1. Geschwindigkeit -> Direkt SQL ist schneller als erst über NST
2. Stabilität -> Falls NST nicht verfügbar funktioniert das trotzdem

und wenn der Update auf 2013 kommt , programmierst du das alles noch einmal

Es ist keine gute Idee mit externen Programmen auf nicht offizielle NAV- Daten zuzugreifen. Die können bei der nächsten Version ganz anders aussehen.

Gruß, Fiddi

Der sicherste Weg, seine NAV-Datenbank in's Nirvana zu schicken: Daten von extern direkt in die NAV-Tabellen der SQL-Datenbank schreiben!
Wenn es unbedingt der direkte Weg sein muss, dann IMMER nur in speziell dafür angelegte Tabellen, welche dann per NAS in regelmäßigen Abständen abgearbeitet werden.
Niemals direkt in die Tabellen der NAV-Geschäftslogik schreiben!

Ich erhalte ca. einmal pro Quartal einen Hilferuf aus unserer Hotline, wo ich dann mit meinem "Rettungs-Report" versuchen darf, die Datenbank zu retten.
Meistens gelingt das damit, ab und zu muss die Datenbank dann doch an Microsoft geschickt oder eine Datensicherung zurückgespielt werden.

Frage am Rande: Warum verwendest du nicht einfach Webservices und lässt dir darüber die gewünschten Daten liefern?

1. Geschwindigkeit -> Direkt SQL ist schneller als erst über NST
2. Stabilität -> Falls NST nicht verfügbar funktioniert das trotzdem

Volker

1. Ist ein Argument. Aber nicht für Links und Notizen.
2. Da wäre es sinnvoller, den Aufwand den du jetzt beim Programmieren der Lösung hast, dafür zu verwenden, dass die NST immer verfügbar ist.

Wozu gibt es denn Webservices, wenn nicht genau für das was du machen willst.

In einem Eintrag in der Tabelle Object steht die komplette Definition des Objekts: Code, Properties, Objekt- Text,...). Die Tabelle Field ist eine virtuelle Tabelle, die auf die Object- Tabelle schaut, um sich die Ergebnisse zu holen.
Gruß, Fiddi

Kann ich nur so bestätigen!

Wenn du die Daten ausliest, warum musst du dann zwischen Code und Text unterscheiden? Die Unterscheidung sollte doch erst beim einfügen per SQL in die Navision-Tabellen wichtig werden (bitte immer über UPPER!).

Beispiel:
Record ID im SQL-Server in der Tabelle Record Link: 0xBA1300000089FF2D31000000
Übersetzung: Tabelle 5050, PK ist ein Code-Feld, und hat den Wert -1, also ein Kontakt mit der No.= -1

Wenn ich nun nach Datensätzen in der Tabelle Record Link im SQL-Server suche und alle Links und Notizen zum Kontakt -1 erhalten möchte, dann muss ich genau diese 3 Infos zusammensetzen.

Alles in SQL:
Aus dem Tabellennamen kann man die NAV-Tabellennummer ermitteln (und umgekehrt; es lässt sich sogar feststellen ob Datapercompany=yes/no).
Den PK kann man abfragen (kann ja auch mehrere Felder umfassen, mit verschiedenen Datentypen. z. B. Sales Line)
Die SQL-Datentypen kann man abfragen.

So wie es aussieht sind die NAV-Datentypen in der Tabelle Object in einem BLOB-Feld gespeichert. Das ist natürlich blöd für eine reine SQL-Lösung.

1. Geschwindigkeit -> Direkt SQL ist schneller als erst über NST
2. Stabilität -> Falls NST nicht verfügbar funktioniert das trotzdem

und wenn der Update auf 2013 kommt , programmierst du das alles noch einmal

Es ist keine gute Idee mit externen Programmen auf nicht offizielle NAV- Daten zuzugreifen. Die können bei der nächsten Version ganz anders aussehen.

Gruß, Fiddi

Na ja, deshalb will ich ja auch ein paar wenige Funktionen, die jede Tabelleninfo auslesen können. Wenn ich das nur für 1 Tabelle bräuchte könnte ich mir die Datentypen der PK in NAV raussuchen und hard-codieren, schließlich weiß man aber nie ob nicht jemand den Pk geändert hat. Und alle Daten bis auf den NAV-Datentyp, kommen vom SQL-Server.

Das mit dem Update ist nur dann ein Argument, wenn mit dem Update auch die Datentypen bestehender Tabellen geändert werden. Dann müßte MS aber auch ein Tool mitliefern die alte Daten lesbar zu halten. Oder was würdest Du sagen, wenn die alten Daten in Record Link von 2009 auf 2013 nicht mehr nutzbar wären?

Volker

Das mit dem Update ist nur dann ein Argument, wenn mit dem Update auch die Datentypen bestehender Tabellen geändert werden. Dann müßte MS aber auch ein Tool mitliefern die alte Daten lesbar zu halten. Oder was würdest Du sagen, wenn die alten Daten in Record Link von 2009 auf 2013 nicht mehr nutzbar wären?

Du verwendest einen nicht offiziellen Weg um auf die Daten zuzugreifen. Was du in NAV siehst und was im SQL- Server tatsächlich abgespeichert wird, ist etwas ganz anderes. Wenn ich mich recht entsinne, ist auch das Format der Links in 2013 geändert worden. (es ist nichts offizielles, und damit "subject to change without notice").

Außerdem kann ich mich Timo und Michael nur anschließen: Man pfuscht nicht direkt in den NAV- Daten auf dem SQL-Server herum.

Gruß, Fiddi

Der sicherste Weg, seine NAV-Datenbank in's Nirvana zu schicken: Daten von extern direkt in die NAV-Tabellen der SQL-Datenbank schreiben!

Das ist mir bewußt und deshalb auch nur lesend.

[quote="m_schneider]...
1. Ist ein Argument. Aber nicht für Links und Notizen.
2. Da wäre es sinnvoller, den Aufwand den du jetzt beim Programmieren der Lösung hast, dafür zu verwenden, dass die NST immer verfügbar ist.

Wozu gibt es denn Webservices, wenn nicht genau für das was du machen willst.[/quote]

Ich betreib den Aufwand damit ich das eben nicht nur für einen Fall verwenden kann, sondern um im Prinzip alle möglichen Daten abfragen zu können und da ist es nun mal ein Unterschied ob ich eine Tabelle mit "Select * from Contact where No_ like 'mycust'" oder mit "Select * from Contact where No_ = 'MYCUST'" abfrage. Das geht aber nur, wenn ich weiss, dass das SQL-Varchar-Feld No_ in NAV ein Code-Feld ist. Im Endeffekt habe ich eine .NET-dll die ich in jedem .NET-Projekt nutzen kann ohne mir um Webservices oder Verbindung zu NAV Gedanken machen zu müssen.

Volker

Außerdem kann ich mich Timo und Michael nur anschließen: Man fuscht nicht direkt in den NAV- Daten auf dem SQL-Server herum.

Ich glaube da stimmen wir alle überein ;)
Die Ausnahme (Spezielle Puffertabellen) hat Timo auch bereits genannt.