Оператор UPDATE работает только с FETCH FIRST

Question

Я пытаюсь обновить таблицу сериалов, указав дату создания соответствующего заказа. В итоге заказы могут иметь повторяющиеся номера, поэтому это соединение необходимо. Ключом на столе является серийный номер.

Я обновляю новое поле MYCRTDAT, используя следующий SQL. Кажется, он работает правильно, но только с оператором FETCH FIRST 1 ROW ONLY. Я проверил, что строки обновлены с правильной датой, быстро просматривая их.

Когда НЕ с использованием этого оператора, он возвращает с ошибкой, что подвыбор базового предиката дал более одной строки

Я думаю, что эта ошибка имеет смысл, но я не понимаю, как VC2.SERIALNUM 'передается' --- это единственное число или все строки одновременно? И если это все строки одновременно, то как FETCH FIRST не просто каждый раз возвращает первую строку?

UPDATE SCHEMA.TABLE VC2
SET MYCRTDAT = (
-- Get Date from Associated Table
SELECT
    MO1.CRDT
FROM 
SCHEMA.TABLE VC1
  LEFT JOIN  SCHEMA.M1 MO1 ON
    VC1.ORDER = MO1.ORDER
    AND VC1.ITEM = MO1.ITEM
WHERE VC2.SERIALNUM = VC1.SERIALNUM
FETCH FIRST 1 ROW ONLY
);

IBM DB2 для i - 7.1 (POWER SERIES)

Answer 1

Я думаю, что лучшей версией этого запроса должна быть инструкция MERGE

MERGE INTO SCHEMA.TABLE VC2
USING SCHEMA.TABLE VC1 LEFT JOIN  SCHEMA.M1 MO1
...
WHEN MATCHED THEN UPDATE MYCRTDAT = MO1.CRDT
else
ignore

Answer 2

У вас есть так называемый коррелированный подзапрос . VC2.SERIALNUM = VC1.SERIALNUM - вот почему это коррелирует.

Концептуально, для каждого значения VC2.serialnum подзапрос выполняется с этим значением.

Таким образом, зачем нужен FETCH FIRST и почему он возвращает первую строку для каждого serailnum.

Вы можете себе представить, коррелированный подзапрос часто работает очень плохо. В некоторых случаях Db может переписать запрос так, чтобы ему не приходилось многократно обращаться к внутренней таблице; особенно в случае UPDATE одного столбца, как у вас.

Возможно, вы захотите взглянуть на оператор MERGE, он должен быть в 7.1.