banner
Heim / Blog / Guru: Abrufen des langen und kurzen Objektnamens
Blog

Guru: Abrufen des langen und kurzen Objektnamens

Jul 30, 2023Jul 30, 2023

14. August 2023 Bob Cozzi

Vor vielen Releases erhielt IBM i „Long SQL Names“ für Dateien und Bibliotheken. Diese neuen längeren Namen (bis zu 128 Zeichen) wurden von SQL-Enthusiasten gut aufgenommen, von den Mainstream-IBM i-Entwicklern jedoch weitgehend ignoriert. Mit jeder neuen Version von IBM i kam es in immer mehr Geschäften zu einem oder mehreren Objekten mit einem Namen, der länger als 10 Zeichen war.

Kürzlich habe ich eine Datei namens BOAT_TRAFFIC erstellt. Dieser Name ist eindeutig länger als 10 Zeichen. Ich habe SQL DDL (die CREATE- oder REPLACE TABLE-Anweisung) verwendet, um die Datei zu erstellen. Die Verwendung von SQL DDL ist die einzige echte Möglichkeit, ein Objekt mit einem langen Namen zu erstellen – die Befehlsschnittstelle des IBM i-Systems (d. h. CL-Befehle) wurde nicht zur Unterstützung langer Namen erweitert. Dies ist keine CL- oder Befehlsbeschränkung. CL-Befehle waren schon immer in der Lage, 128-Byte-Namen zu unterstützen – tatsächlich wurde 1980, als ich meinen ersten vom Benutzer geschriebenen CL-Befehl schrieb, versehentlich eine Länge von 32 für den Objektnamenparameter angegeben und es funktionierte! Es scheint, dass die Aktualisierung des Kern-CL zur Unterstützung langer Objekt- und Bibliotheksnamen „niemals passieren wird“.

Hier ist eine gekürzte Version der SQL-DLL, die ich zum Erstellen der BOAT_TRAFFIC-Datei (ich meine Tabelle) verwendet habe:

Wenn ich diese Datei in eine Entwicklerbibliothek oder eine Sicherungsbibliothek kopieren würde, würde ich je nach Kontext normalerweise CRTDUPOBJ oder CPYF verwenden. Nehmen wir an, ich möchte CPYF verwenden, weil ich die Daten in einer Entwicklerbibliothek mit den aktuellen Daten aktualisieren möchte. Ich würde am Ende einen Befehlseingabebildschirm erhalten, der wie im Bild unten aussieht:

Ich könnte tatsächlich SQL verwenden, um den Kopiervorgang durchzuführen. Ich müsste zuerst die Daten in der Zieldatei löschen und dann die neuen Daten mit der SQL-Anweisung INSERT kopieren. Vielleicht so etwas:

Ich sage, das funktioniert, weil ich (A) die Zieldatei mit der TRUNCATE-Anweisung oder einer ähnlichen Anweisung löschen muss und (B) die Datensätze kopieren und dabei die IDENTITY-Spalte berücksichtigen muss. Dazu füge ich den OVERRIDING XXX VALUE wie folgt zur INSERT-Anweisung hinzu:

Wenn Zeilen zu einer Datei hinzugefügt werden, die eine IDENTITY-Spalte enthält, erhöht die Datenbank normalerweise automatisch die IDENTITY-Spalte. Um dies zu umgehen, können Sie die Klausel OVERRIDING USER VALUE oder OVERRDING SYSTEM VALUE verwenden.

ÜBERSCHREITENDER BENUTZERWERT bedeutet, dass die Unterabfrage von INSERT (dh die SELECT-Anweisung) den IDENTITY-Spaltenwert enthält, Sie möchten jedoch, dass das System diesen Wert ignoriert und für jede neu hinzugefügte Zeile einen neuen generiert.

ÜBERSCHREIBENDER SYSTEMWERT bedeutet, dass die Unterabfrage von INSERT (dh die SELECT-Anweisung) den IDENTITY-Spaltenwert enthält und Sie möchten, dass das System diesen Wert beibehält, indem es ihn in die Zieldatei kopiert.

In diesem Beispiel wollen wir eindeutig den ÜBERSCHREIBENDEN SYSTEMWERT.

Neben Datenbankdateien verfügt SQL über weitere Objekte. SEQUENCE, ALIAS, FUNCTION, PROCEDURE usw. Alle diese unterstützen bis zu 128 Byte lange SQL-Namen. Angenommen, wir erstellen einen SQL-ALIAS und geben ihm einen langen Namen. ALIAS-Objekte werden häufig von IBM i-Shops typischerweise für die Mitgliederverarbeitung verwendet. Da SQL keine Kenntnis von Mitgliedern hat, hat IBM ALIAS so erweitert, dass sie für den Zugriff auf bestimmte Mitglieder einer Datei verwendet werden können.

In diesem Beispiel habe ich in der CUSTOMS-Bibliothek einen ALIAS namens BOAT_TARIFF_BAHAMAS erstellt. Ich kann diesen ALIAS in einer SELECT-Anweisung verwenden, um das BAHAMAS-Mitglied der TARIFF-Datei abzufragen. ALIAS speichern wie alle anderen SQL-Typen den Langnamen im IBM i-Systemobjektnamen im SQL-Katalog.

Datenbankdateien speichern ihren langen SQL-Namen in der Objektbeschreibung der Datei und ermöglichen den Zugriff auf diesen Namen über die QDBRTVFD-API. Es gibt auch eine weitere API namens Retrieve Short Name (QDBRTVSN), die den IBM i-Objektnamen für lange SQL-Namen zurückgibt. Dies gilt jedoch auch nur für Datenbankdateien und neuerdings auch für Bibliotheksnamen.

Alle anderen Objekttypen, die einen langen SQL-Namen haben, werden im SQL-Katalog referenziert. IBM verwendet bei seinen Katalognamen eine ziemlich konsistente Namenskonvention, sodass Sie sich einigermaßen leicht merken können, welche Kataloge Sie abfragen müssen. Hier ist eine Liste der Katalogdateinamen, die die Eigenschaften für alle SQL-Objekte und viele IBM i-Objekte enthält, die implizit SQL-Objekte sind (z. B. physische und logische Dateien):

Der SYSTABLES-Katalog wird für verschiedene Arten von Dateien/Tabellen verwendet, darunter:

Ich habe vor ein paar Jahren damit begonnen, die QDBRTVSN-API zu verwenden, um einen langen SQL-Namen in den kurzen IBM i-Systemobjektnamen umzuwandeln. Aber als ich anfing, SEQUENZEN, Funktionen, Trigger usw. zu verwenden, war ich frustriert. Mein erster Ansatz bestand darin, den Katalog zu verwenden und die spezifische Katalogdatei basierend auf dem Typ dynamisch abzufragen. Dies war jedoch nicht immer intuitiv oder praktisch. Also habe ich eine bessere Schnittstelle entwickelt.

Die SQL-Funktion GETOBJNAME akzeptiert einen regulären kurzen IBM i-Systemobjektnamen und eine Bibliothek oder einen langen SQL-Namen und einen langen oder kurzen Schemanamen und gibt sowohl den langen als auch den kurzen Namen für das Objekt an den Aufrufer zurück. Es wird nur eine Zeile mit allen sechs Attributen zurückgegeben, einschließlich:

Hier ist ein Beispiel für die Verwendung in RPG IV:

Die SQL-Funktion „GetObjName“ gibt sowohl den Lang- als auch den Kurznamen für jedes Objekt zurück. Die überwiegende Mehrheit Ihrer Objekte wird nur kurze Namen und wahrscheinlich keinen SQL-Objekttyp haben. Wenn dies der Fall ist, enthalten die Spalten LONGOBJNAME und LONGOBJLIB dieselben Werte wie die Spalten OBJNAME bzw. OBJLIB, und SQL_OBJECT_TYPE ist NULL.

GETOBJNAME funktioniert auf IBM i 7.2 und höher. Um die Funktion auf Ihrem System zu erstellen, kopieren Sie den folgenden Code, fügen Sie ihn in ein Quellmitglied ein und führen Sie den Befehl RUNSQLSTM über dieses Mitglied aus. Alternativ können Sie den Code in die IBM ACS RUN SQL Scripts-Schnittstelle einfügen und direkt ausführen. Beachten Sie, dass dies der verwendete Bibliotheks-/Schemaname ist, da es mit SQL Tools ausgeliefert wird.

Wenn Sie das GitHub-Ding bevorzugen, können Sie zu meiner GitHub-Seite unter https://github.com/bobcozzi/GETOBJNAME gehen und es direkt herunterladen.

Bob Cozzi ist IBM i-Auftragnehmer und -Berater sowie Autor von The Modern RPG Language, Entwickler von SQL iQuery und SQL Tools und Redner zu SQL- und RPG IV-Themen, die Sie tatsächlich verwenden können.

Guru: Objektnutzungsstatistik

Guru: Verbindliche Verzeichniseinträge

Guru: Finden Sie ungenutzte Objekte auf IBM i mithilfe von SQL

Was ist in den Top 5 der angesagtesten IBM i RFEs?

Cozzi verfeinert datenzentrierte Ideen für IBM i Report Writer

Cozzi aktualisiert RPG xTools und arbeitet mit Linoma zusammen