#db2 #db2-luw
#db2 #db2-luw
Вопрос:
При выполнении следующего оператора он печатает измененные строки с атомарным, но не без него. Однако я не нашел в документации ничего, что объясняло бы это поведение.
--#SET TERMINATOR @
drop table mytable@
CREATE TABLE mytable (
col1 INTEGER
) @
SELECT * FROM new TABLE (INSERT INTO mytable (col1) VALUES (1)) @
SELECT * FROM mytable @
BEGIN ATOMIC
SELECT col1 FROM new TABLE (INSERT INTO mytable (col1) VALUES (2));
END @
SELECT * FROM mytable @
BEGIN
SELECT col1 FROM new TABLE (INSERT INTO mytable (col1) VALUES (3));
END @
Я получил этот вывод:
Комментарии:
1.
BEGIN ATOMICв соответствии с вашим примером ничего не печатается. Выходные строки печатаются с помощью последующего оператора select .BEGIN ATOMICОператор выводит только информацию об успешном завершении вместо ожидаемого сбоя, как дляBEGIN NOT ATOMIC(последнего оператора).2. @MarkBarinstein AngocA спрашивает, почему SQL0104N происходит в одном случае, но не в другом (учитывая, что оператор SELECT бесполезен в любом случае)?
3. @mao Исходное утверждение было: «он печатает измененные строки с помощью Atomic». Но он не печатает никаких строк ни в одном составном (атомарном или неатомном) операторе. Единственное странное поведение для меня здесь заключается в том, что он действительно не возвращает SQL0104N для оператора select во встроенном (атомарном) составном операторе. Кажется, что это какая-то недокументированная «особенность» db2 (не только CLP). Это может быть действительно полезно для таких выборок из операции изменения данных. Какой-то вывод в /dev/null .
4. @MarkBarinstein . Несоответствие между АТОМАРНЫМ / НЕАТОМНЫМ в этом случае вызывает беспокойство, поскольку кажется естественным ожидать одинакового результата в обоих случаях. Но поведение, похоже, таково, что АТОМАРНЫЙ случай каким-то образом обрабатывает исключение и подавляет его, в то время как НЕАТОМНЫЙ случай не обрабатывает исключение и корректно выдает его.
5. может быть, стоит обратиться в службу поддержки IBM