Гуру: получение длинного и короткого имени объекта

Jul 30, 2023

14 августа 2023 г. Боб Коцци

Много выпусков назад IBM i получила «длинные имена SQL» для файлов и библиотек. Эти новые более длинные имена (до 128 символов) были хорошо приняты энтузиастами SQL, но в значительной степени проигнорированы основными разработчиками IBM i. С появлением каждой версии IBM i все больше и больше магазинов встречали один или несколько объектов с именем длиной более 10 символов.

Недавно я создал файл с именем BOAT_TRAFFIC. Это имя явно длиннее 10 символов. Для создания файла я использовал SQL DDL (оператор CREATE или REPLACE TABLE). Использование SQL DDL — единственный реальный способ создать объект с длинным именем: командный интерфейс системы IBM i (т. е. команды CL) не был улучшен для поддержки длинного имени. Это не ограничение CL или команды. Команды CL всегда могли поддерживать 128-байтовые имена — фактически, еще в 1980 году, когда я написал свою первую написанную пользователем команду CL, она случайно указала длину 32 для параметра имени объекта, и это сработало! Похоже, что обновление ядра CL для поддержки длинных имен объектов и библиотек «никогда не произойдет».

Вот сокращенная версия SQL DLL, которую я использовал для создания файла BOAT_TRAFFIC (я имею в виду таблицу):

Если бы мне нужно было скопировать этот файл в библиотеку разработчика или резервную библиотеку, я бы обычно использовал CRTDUPOBJ или CPYF в зависимости от контекста. Допустим, я хочу использовать CPYF, потому что хочу обновить данные в библиотеке разработчика текущими данными. В итоге у меня получится экран ввода команд, похожий на изображение ниже:

Я мог бы использовать SQL для выполнения операции копирования. Сначала мне нужно было очистить данные в целевом файле, а затем скопировать новые данные с помощью оператора SQL INSERT. Возможно, что-то вроде этого:

Я говорю, что это работает, потому что мне нужно (А) очистить целевой файл с помощью оператора TRUNCATE или аналогичного оператора и (Б) скопировать записи, включив в них столбец IDENTITY. Для этого я добавляю OVERRIDING XXX VALUE к оператору INSERT следующим образом:

Обычно, когда строки добавляются в файл, содержащий столбец IDENTITY, база данных автоматически увеличивает столбец IDENTITY. Чтобы обойти это, вы можете использовать предложение OVERRIDING USER VALUE или OVERRDING SYSTEM VALUE.

ПЕРЕОПРЕДЕЛЕНИЕ ЗНАЧЕНИЯ ПОЛЬЗОВАТЕЛЯ означает, что подзапрос INSERT (т. е. оператор SELECT) содержит значение столбца IDENTITY, но вы хотите, чтобы система игнорировала это значение и создавала новое для каждой вновь добавленной строки.

ПЕРЕОПРЕДЕЛЕНИЕ СИСТЕМНОГО ЗНАЧЕНИЯ означает, что подзапрос INSERT (т. е. оператор SELECT) содержит значение столбца IDENTITY, и вы хотите, чтобы система сохранила это значение, скопировав его в целевой файл.

Очевидно, что в этом примере мы хотим ПЕРЕОПРЕДЕЛИТЬ СИСТЕМНОЕ ЗНАЧЕНИЕ.

Помимо файлов базы данных, в SQL есть и другие объекты; SEQUENCE, ALAS, FUNCTION, PROCEDURE и т. д. Все они поддерживают имена SQL длиной до 128 байт. Например, предположим, что мы создали псевдоним SQL и присвоили ему длинное имя. Объекты ALIAS часто используются магазинами IBM i, как правило, для обработки участников. Поскольку SQL не знает об элементах, IBM усовершенствовала псевдонимы, чтобы их можно было использовать для доступа к определенным элементам файла.

В этом примере я создал псевдоним с именем BOAT_TARIFF_BAHAMAS в библиотеке CUSTOMS. Я могу использовать этот ALIAS в инструкции SELECT для запроса элемента BAHAMAS файла TARIFF. В псевдонимах, как и во всех других типах SQL, длинное имя хранится в имени системного объекта IBM i в каталоге SQL.

Файлы базы данных хранят свое длинное имя SQL в описании объекта файла и предоставляют доступ к этому имени через API QDBRTVFD. Существует также другой API под названием «Получить короткое имя» (QDBRTVSN), который возвращает имя объекта IBM i для длинных имен SQL. Однако это также применимо только к файлам баз данных, а в последнее время и к именам библиотек.

Все остальные типы объектов, имеющие длинное имя SQL, имеют перекрестные ссылки в каталоге SQL. IBM использует довольно единообразное соглашение об именах своих каталогов, что позволяет легко запомнить, какие каталоги вам нужно запросить. Ниже приведен список имен файлов каталога, содержащий свойства всех объектов SQL и многих объектов IBM i, которые неявно являются объектами SQL (например, физические и логические файлы):