DDS Feldname ermitteln

[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.

[Fuerchau]

Das wäre auf jeden Fall ein BUG und gehört entweder gemeldet oder ist bereits durch ein PTF behoben !!!

Es wäre FATAL, wenn das Systemrepository durch den Restore nicht angepasst würde.

Nochmal:
Beim Create Collection werden SYS-Datein als Views in die neue Lib eingetragen.
Create Table und co. füllen das Systemrepository und sind direkt per SYS-Objekte sowohl aus QSYS2 als auch aus der Lib abfragbar.

Wenn ich nun bei einer Systemwiederherstellung (nacktes System) und einem Restore meiner DB die SYS-Objekte nicht gepflegt würden könnte ich meine ganze Anwendung vergessen, da ich ja sämtliche Tables/Views/Trigger/Functions/Procedures u.v.m. komplett neu erstellen müsste.

Es funktioniert ja sogar mit SQL-Triggern/Funktionen/Prozeduren wenn ich diese von einem auf das andere System übertrage, da entsprechende SQL-Informationen in den Programmen abgelegt werden.