Guru : Récupération du nom d'objet long et court

Jul 30, 2023

14 août 2023Bob Cozzi

Il y a de nombreuses versions, IBM i recevait des « noms SQL longs » pour les fichiers et les bibliothèques. Ces nouveaux noms plus longs (jusqu'à 128 caractères) ont été bien accueillis par les passionnés de SQL, mais largement ignorés par les principaux développeurs IBM i. À mesure que chaque version d'IBM i émergeait, de plus en plus de magasins utilisaient un ou plusieurs objets portant un nom de plus de 10 caractères.

Récemment, j'ai créé un fichier nommé BOAT_TRAFFIC. Ce nom comporte clairement plus de 10 caractères. J'ai utilisé SQL DDL (l'instruction CREATE ou REPLACE TABLE) pour créer le fichier. L'utilisation de SQL DDL est le seul véritable moyen de créer un objet avec un nom long : l'interface de commande du système IBM i (c'est-à-dire les commandes CL) n'a pas été améliorée pour prendre en charge les noms longs. Il ne s'agit pas d'une limitation de CL ou de commande. Les commandes CL ont toujours été capables de prendre en charge des noms de 128 octets. En fait, en 1980, lorsque j'ai écrit ma première commande CL écrite par l'utilisateur, elle a accidentellement spécifié une longueur de 32 pour le paramètre de nom d'objet et cela a fonctionné ! Il semble que la mise à jour du noyau CL pour prendre en charge les noms d’objets et de bibliothèques longs « n’arrivera jamais ».

Voici une version abrégée de la DLL SQL que j'ai utilisée pour créer le fichier BOAT_TRAFFIC (je veux dire Table) :

Si je devais copier ce fichier dans une bibliothèque de développeur ou une bibliothèque de sauvegarde, j'utiliserais généralement CRTDUPOBJ ou CPYF selon le contexte. Disons que je souhaite utiliser CPYF car je souhaite actualiser les données d'une bibliothèque de développeur avec les données actuelles. Je me retrouverais avec un écran de saisie de commande qui ressemble à l'image ci-dessous :

Je pourrais en fait utiliser SQL pour effectuer l'opération de copie. Je devrais d'abord effacer les données du fichier cible, puis copier les nouvelles données à l'aide de l'instruction SQL INSERT. Peut-être quelque chose comme ça :

Je dis que ce genre de travail fonctionne, car je dois (A) effacer le fichier cible à l'aide de TRUNCATE ou d'une instruction similaire, et (B) copier les enregistrements tout en tenant compte de la colonne IDENTITY. Pour ce faire, j'ajoute la OVERRIDING XXX VALUE à l'instruction INSERT comme ceci :

Normalement, lorsque des lignes sont ajoutées à un fichier comportant une colonne IDENTITY, la base de données incrémente automatiquement la colonne IDENTITY. Pour contourner cela, vous pouvez utiliser la clause OVERRIDING USER VALUE ou la clause OVERRDING SYSTEM VALUE.

OVERRIDING USER VALUE signifie que la sous-requête INSERT (c'est-à-dire l'instruction SELECT) contient la valeur de la colonne IDENTITY, mais vous souhaitez que le système ignore cette valeur et en génère une nouvelle pour chaque ligne nouvellement ajoutée.

OVERRIDING SYSTEM VALUE signifie que la sous-requête INSERT (c'est-à-dire l'instruction SELECT) contient la valeur de la colonne IDENTITY et que vous souhaitez que le système conserve cette valeur en la copiant dans le fichier cible.

Clairement, dans cet exemple, nous voulons REMPLACER LA VALEUR DU SYSTÈME.

Outre les fichiers de base de données, SQL possède d’autres objets ; SÉQUENCE, ALIAS, FONCTION, PROCÉDURE, etc. Tous prennent en charge des noms SQL jusqu'à 128 octets. Par exemple, supposons que nous créions un ALIAS SQL et que nous lui donnions un nom long. Les objets ALIAS sont souvent utilisés par les magasins IBM i, généralement pour le traitement des membres. Étant donné que SQL ne connaît pas les membres, IBM a amélioré les ALIAS afin qu'ils puissent être utilisés pour accéder à des membres spécifiques d'un fichier.

Dans cet exemple, j'ai créé un ALIAS nommé BOAT_TARIFF_BAHAMAS dans la bibliothèque CUSTOMS. Je peux utiliser cet ALIAS dans une instruction SELECT pour interroger le membre BAHAMAS du fichier TARIFF. Les ALIAS, comme tous les autres types SQL, stockent le nom long du nom de l'objet système IBM i dans le catalogue SQL.

Les fichiers de base de données stockent leur nom SQL long dans la description de l'objet du fichier et donnent accès à ce nom via l'API QDBRTVFD. Il existe également une autre API nommée Retrieve Short Name (QDBRTVSN) qui renvoie le nom d'objet IBM i pour les noms SQL longs. Cependant, cela ne s'applique également qu'aux fichiers de base de données et, plus récemment, aux noms de bibliothèques.

Tous les autres types d'objets portant un nom SQL long font l'objet de références croisées dans le catalogue SQL. IBM utilise une convention de dénomination assez cohérente avec ses noms de catalogue, ce qui facilite la mémorisation des catalogues que vous devez interroger. Voici une liste des noms de fichiers catalogue contenant les propriétés de tous les objets SQL et de nombreux objets IBM i qui sont implicitement des objets SQL (tels que les fichiers physiques et logiques) :