Доступ к определенной строке DB2 в неуникальной таблице для операций обновления/удаления
Могу ли я выполнять операции обновления/удаления строк в таблице DB2 через SQL в контексте первичного ключа НЕ QUNIQUE?
Таблица представляет собой ФИЗИЧЕСКИЙ ФАЙЛ в СОБСТВЕННОЙ СИСТЕМЕ AS/400. Как и многие другие Файлы, он был создан без уникального определения, что приводит DB2 к выводу, что у Таблицы или PF нет уникального ключа.
И это моя проблема. Я не могу переопределить структуру таблицы, чтобы вставить уникальный ID ROW, потому что мне пришлось бы перекомпилировать ВСЕ мои коррелирующие программы на AS/400, что является серьезной проблемой, многое больше не будет работать, "возможно" . Конечно, я могу сделать такой рефакторинг для одной таблицы, но в нашей системе есть тысячи таких нативных ФАЙЛОВ, некоторые хорошо сделаны с уникальным ключом, некоторые без уникального определения...
Ну, большую часть времени я работаю с db2 и sql над этими старыми файлами. И все файлы, которые имеют УНИКАЛЬНЫЙ ключ, не являются для меня проблемой для выполнения этих важных операций обновления/удаления.
Есть ли способ получить дополнительный столбец для каждого выбора с очень уникальным идентификатором строки, соответствующим номером строки. И вдобавок, что гораздо важнее, как мне обновить этот RowNumber.
Я провел некоторое исследование и тем временем предполагаю, что нет возможности делать точные изменения или удаления, когда нет уникального ключа. Я бы хотел, чтобы был какой-то дополнительный ID-ROW, который всегда отправляется с таблицей, на который я могу ссылаться, когда выполняю операции обновления/удаления. Возможно, мое мышление здесь ошибочно, поскольку таблицы неуникальных ключей предназначены для редактирования другими способами.
Ответы 1
Попробуйте функцию РРН.
SELECT RRN(EMPLOYEE), LASTNAME
FROM EMPLOYEE
WHERE ...;
UPDATE EMPLOYEE
SET ...
WHERE RRN(EMPLOYEE) = ...;
@dc-deal БУДЬТЕ ОСТОРОЖНЫ! RRN может измениться, если будет выполнен RGZPFM, поэтому используйте его только для немедленного использования.
Большое спасибо, это так! Точно, мне немного стыдно, что я не нашел его сам, но я искал свою задницу. К сожалению, на мой взгляд, справка IBM не очень хорошо структурирована, или я был слишком глуп :]. Еще раз спасибо!