Guru: recupero del nome dell'oggetto lungo e breve

Jul 30, 2023

August 14, 2023 Bob Cozzi

Molte versioni fa, IBM i ha ricevuto "nomi SQL lunghi" per file e librerie. Questi nuovi nomi più lunghi (fino a 128 caratteri) furono ben accolti dagli appassionati di SQL, ma in gran parte ignorati dallo sviluppatore mainstream IBM i. Con l'emergere di ogni versione di IBM i, sempre più negozi sperimentavano uno o più oggetti con un nome più lungo di 10 caratteri.

Recentemente ho creato un file chiamato BOAT_TRAFFIC. Questo nome è chiaramente più lungo di 10 caratteri. Ho utilizzato SQL DDL (l'istruzione CREATE o REPLACE TABLE) per creare il file. L'utilizzo di SQL DDL è l'unico vero modo per creare un oggetto con un nome lungo: l'interfaccia di comando del sistema IBM i (ovvero i comandi CL) non è stata migliorata per supportare il nome lungo. Questa non è una limitazione CL o di comando. I comandi CL sono sempre stati in grado di supportare nomi da 128 byte: infatti, nel 1980, quando scrissi il mio primo comando CL scritto dall'utente, specificava accidentalmente una lunghezza di 32 per il parametro del nome dell'oggetto e funzionava! Sembra che l'aggiornamento del CL core per supportare nomi lunghi di oggetti e librerie "non accadrà mai".

Ecco una versione abbreviata della DLL SQL che ho utilizzato per creare il file BOAT_TRAFFIC (intendo Tabella):

Se dovessi copiare questo file in una libreria per sviluppatori o in una libreria di backup, in genere utilizzerei CRTDUPOBJ o CPYF a seconda del contesto. Diciamo che voglio utilizzare CPYF perché voglio aggiornare i dati in una libreria per sviluppatori con i dati correnti. Alla fine mi ritroverei con una schermata di immissione dei comandi simile all'immagine seguente:

Potrei effettivamente usare SQL per eseguire l'operazione di copia. Dovrei prima cancellare i dati nel file di destinazione e quindi copiare i nuovi dati utilizzando l'istruzione SQL INSERT. Forse qualcosa del genere:

Dico che questo tipo di lavoro funziona, perché devo (A) cancellare il file di destinazione utilizzando TRUNCATE o un'istruzione simile e (B) copiare i record adattando la colonna IDENTITY. Per fare ciò, aggiungo OVERRIDING XXX VALUE all'istruzione INSERT in questo modo:

Normalmente quando vengono aggiunte righe a un file che ha una colonna IDENTITY, il database incrementa automaticamente la colonna IDENTITY. Per aggirare ciò, è possibile utilizzare la clausola OVERRIDING USER VALUE o la clausola OVERRDING SYSTEM VALUE.

OVERRIDING USER VALUE significa che la sottoquery di INSERT (ovvero l'istruzione SELECT) contiene il valore della colonna IDENTITY, ma si desidera che il sistema ignori quel valore e ne generi uno nuovo per ogni riga appena aggiunta.

OVERRIDING SYSTEM VALUE significa che la sottoquery di INSERT (ovvero l'istruzione SELECT) contiene il valore della colonna IDENTITY e si desidera che il sistema mantenga tale valore copiandolo nel file di destinazione.

Chiaramente in questo esempio, vogliamo OVERRIDING SYSTEM VALUE.

Oltre ai file di database, SQL ha altri oggetti; SEQUENZA, ALIAS, FUNZIONE, PROCEDURA, ecc. Tutti questi supportano nomi SQL lunghi fino a 128 byte. Ad esempio, supponiamo di creare un ALIAS SQL e di assegnargli un nome lungo. Gli oggetti ALIAS vengono spesso utilizzati dai centri IBM i, in genere per l'elaborazione dei membri. Poiché SQL non riconosce i membri, IBM ha migliorato gli ALIAS in modo che possano essere utilizzati per accedere a membri specifici di un file.

In questo esempio, ho creato un ALIAS denominato BOAT_TARIFF_BAHAMAS nella libreria CUSTOMS. Posso utilizzare questo ALIAS in un'istruzione SELECT per interrogare il membro BAHAMAS del file TARIFF. Gli ALIAS, come tutti gli altri tipi SQL, memorizzano il nome lungo nel nome dell'oggetto del sistema IBM i nel catalogo SQL.

I file di database memorizzano il loro nome SQL lungo nella descrizione dell'oggetto del file e forniscono l'accesso a quel nome tramite l'API QDBRTVFD. Esiste anche un'altra API denominata Retrieve Short Name (QDBRTVSN) che restituisce il nome dell'oggetto IBM i per i nomi SQL lunghi. Tuttavia, anche questo si applica solo ai file di database e, più recentemente, ai nomi delle librerie.

Tutti gli altri tipi di oggetto che hanno un nome SQL lungo presentano riferimenti incrociati nel catalogo SQL. IBM utilizza una convenzione di denominazione abbastanza coerente con i nomi dei cataloghi, rendendo in qualche modo facile ricordare quali cataloghi è necessario interrogare. Di seguito è riportato un elenco dei nomi dei file di catalogo che contengono le proprietà per tutti gli oggetti SQL e molti oggetti IBM i che sono implicitamente oggetti SQL (come file fisici e logici):