DDS Feldname ermitteln

[Fuerchau]

Korrektur: QADBIFLD
Allerdings fehlt da ggf. die Public-Berechtigung für den Zugriff.

Die Korrekte Tabelle für SQL ist die QSYS2.SYSCOLUMNS !
Diese enthält den kurzen und auch langen Namen.

Allerdings sind diese Infos nicht per Metadaten abfragbar sondern müssen per eigenem SQL gelesen werden.

Achtung:
Je nach Treiberversion können Abfragen auf SYSCOLUMNS als Metadaten-Abfrage interpretiert werden, so dass das Resultset ggf. abweichende Feldnamen enthält als man im SQL-Statement benannt hat (aus NAME wird z.B. COLUMN_NAME).

[KM]

Hallo Karsten,

wenn Du sowohl ALIAS als auch COLHDG verwendest, hast Du wohl schlechte Karten.

Die Methode getColumnLabel ermittelt nämlich den Wert von COLHDG und die Methode getColumnName den Wert von ALIAS.

Wenn Du auf COLHDG verzichten könntest, würde getColumnLabel den Feldnamen ermitteln. Und wenn Du auf ALIAS verzichten könntest, würde getColumnName den Feldnamen ermitteln.

An dieser Stelle ist der JDBC-Treiber wirklich noch verbesserungswürdig.

Gruß,
KM

[Fuerchau]

Vorsicht !

COLHDG hat mit NAME und ALIAS überhaupt nichts zu tun.

Beim CREATE TABLE wird sowohl der Name asl auch der ALIAS gesetzt. COLHDG bekommt erst mal den ALIAS-Namen und kann mittels LABEL ON geändert werden.

COLHDG spiegelt also in keinster Weise den langen Namen wieder sondern nur die zu verwendende Überschrift.

Der JDBC-Treiber verhält sich da vollkommen korrekt !!!

[KM]

Das mag für SQL-DDL beschriebene Tabellen durchaus zutreffen. Da das hier aber nicht gefragt war, sondern es sich laut Karsten um DDS handelt, verhalten sich die Methoden getColumnName und getColumnLabel so wie ich es oben beschrieben habe, je nach Vorkommen der Schlüsselwörter ALIAS bzw. COLHDG.

Gruß,
KM

[Fuerchau]

Das ist unerheblich für SQL oder DDS, da ich ähnliches in beiden erreichen kann.

In DDS definiere ich den 10-stelligen Namen.
Tue ich nichts weiter, gilt dieser auch für SQL, COLHDG wird automatisch gesetzt.
Mit ALIAS definiere ich den (ggf.) langen Namen. COLHDG wird nun automatisch mit dem ALIAS gefüllt.
Nun kann ich noch zusätzlich auch COLHDG selber bestimmen !

A MYFIELD 30 ALIAS('MySQL-Field')
COLHDG('Zeile 1' 'Zeile 2' 'Zeile 3)

Mit SQL kann ich nun sowohl auf MYFIELD als auch auf "MySQL-Field" zugreifen (beachte die Anführungszeichen).

getColumnName liefert immer "MySQL-Field"
getColumnLabel liefert immer "Zeile 1 Zeile 2 Zeile 3"

In SQL muss ich

"MySql-Field" FOR COLUMN MYSQLFLD

definieren. Mit
LABEL ON COLUMN FILE (MYSQLFLD IS 'Zeile 1')

wird dann die Überschrift definiert.

Fazit:
ALIAS und COLHDG können GLEICHZEITIG verwendet werden.

[KM]

Natürlich können ALIAS und COLHDG gleichzeitig benutzt werden. Nur hat man dann halt leider keine Möglichkeit mehr mit den Java-Methoden getColumnName und getColumnLabel auf den ursprünglichen Feldnamen zuzugreifen. Das versuche ich doch die ganze Zeit zu erklären. Außerdem stimmt es nicht, dass COLUMN_HEADING mit dem ALIAS-Namen gefüllt wird, so wie Du es geschrieben hast, sondern standardmäßig steht der ursprüngliche Feldname in COLUMN_HEADING, völlig unabhängig von ALIAS. Erst wenn das Schlüsselwort COLHDG explizit angegeben wird, wird der Text geändert. Deshalb war mein Vorschlag ja auch evtl. auf das Schlüsselwort ALIAS oder COLHDG zu verzichten, um somit auf den Feldnamen zugreifen zu können. Das Problem beim JDBC-Treiber ist nun mal, dass man mit keiner Methode den ursprünglichen Feldnamen (SYSTEM_COLUMN_NAME) ermitteln kann, sondern nur den SQL-Feldnamen bzw. den ALIAS-Namen.

Gruß,
KM

[Fuerchau]

OK, dem kann ich zustimmen.
Um auf den originären Feldnamen zuzugreifen muss man dann halt leider selbst auf die SYSCOLUMNS zugreifen.
In der Spalten SYS_xNAME stehen die jeweiligen 10-stelligen Namen.

Allerdings ist man dann nicht mehr Systemunabhängig, da nur die Metadaten-Info's weitgehends normiert sind und für den Zugriff per SQL (ODBC/JDBC) vollkommen ausreichen.

Ich wollte ja auch nur darauf hinweisen, dass man sich eben auf getColumnLabel als Kurznamen nicht verlassen kann, da ja jederzeit per LABEL ON die Überschrift geändert werden kann und somit COLHDG nicht mit dem kurzen Namen identisch sein muss.

Der OpsNav erlaubt da nämlich sehr schnell und einfach ein umlabeln.

[pwrdwnsys]

Danke für die vielen Tips, da in der zugrunde liegenden Anwendung IMMER COLHDG verwedet wird, fällt also die Version mit getLabelName() aus. Werde ich wohl auf die Systemtabellen zurückgreifen. Da ich erst morgen wieder im Büro bin noch ein kurzer Denkanstoß: Sie die SYCOLUMNS eigentlich auch bei Erstellung von DDS-Dateien gefüllt ? Außerdem habe ich festgestellt, das, wenn Tabellen, welche mit CREATE TABLE auf System A erstellt und dann die Bibliothek mit SAVLIB / RSTLIB auf System B restoret wird, die Systemtabellen /Systables, Syscolumns usw) nicht gefüllt sind. Da die logischen SYS... tabellen in der jeweiligen Bibliothek ja auf die QUSRSYS zeigen, kann entweder deren Inhalt mitgenommen werden (was ich nicht empfehlen würde, denn das gibt Datensalat) oder die Tabellen einmal auf System B erstellt werden. Oder gibt es da eine elegantere Lösung ?

[Fuerchau]

getLabelName liefert doch COLHDG zurück !

Die QSYS2/SYS-Tabellen sind Views/LF's auf die QSYS/QADB-Dateien und werden automatisch beim RST gepflegt.
Wenn dies nicht der Fall sein sollte, RCLSTG *DBXREF durchführen.

Durch CREATE COLLECTION/SCHEMA werden entsprechende SYS-Views in die neue Lib erstellt. Diese verweisen aber auch auf die QSYS.QADB-Dateien.

[KM]

Hallo pwrdwnsys,

die Datei SYSCOLUMNS wird auch bei DDS-Dateien gepflegt, da es ja nur eine logische Datei zu QADBXREF ist, in der alle Dateien vorhanden sind. Wir arbeiten fast ausschließlich mit DDS-Dateien. Und diese sind alle darin enthalten.

Beim SAVxxx/RSTxxx müsste die Datei auch gepflegt werden. Wir erstellen z.B. auch sämtliche Dateien auf System A und übertragen sie mit SAVRSTOBJ auf System B. Und in SYSCOLUMNS auf System B sind alle Dateien vorhanden.

@Fuerchau:

getLabelName liefert doch COLHDG zurück !

Genau aus diesem Grund kann er es ja nicht verwenden. Er will ja den Feldnamen und nicht COLHDG.

Gruß,
KM

[pwrdwnsys]

Hallo pwrdwnsys,

die Datei SYSCOLUMNS wird auch bei DDS-Dateien gepflegt, da es ja nur eine logische Datei zu QADBXREF ist, in der alle Dateien vorhanden sind. Wir arbeiten fast ausschließlich mit DDS-Dateien. Und diese sind alle darin enthalten.

Beim SAVxxx/RSTxxx müsste die Datei auch gepflegt werden. Wir erstellen z.B. auch sämtliche Dateien auf System A und übertragen sie mit SAVRSTOBJ auf System B. Und in SYSCOLUMNS auf System B sind alle Dateien vorhanden.


Gruß,
KM

KM, das mit dem SAV / RST stimmt, gilt aber leider nur für DDS-Dateien. Habs gerade ausprobiert. Alles, was mit SQL erstellt wird (auch wenn die Bibliothek mit CREATE DATABASE erstellt wird) wird beim RESTORE leider NICHT nachgezogen.