|
AS400 DB2, errors handling
|
|||
---|---|---|---|
#18+
Всем привет. Уважаемые знатоки, подскажите.. По работе поддерживаем некий ETL процесс на DB2 сервере, построенный на множесве хранимых процедур. Пытаюсь встроить в них обработку и логгирование ошибок, ориентируясь на примеры отсуда https://www.itjungle.com/2017/10/30/guru-logging-sql-errors-warnings/ В моем коде это выглядит таким образом Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
То есть по замыслу хранимка, словив произвольный SQL exception, пишет сначала запись об этом в лог, после этого снова его же выкидывает. Все работает нормально, за исключением того, что обработчик реагирует не только на exception, но на на waring. -например, если пытаться сделать truncate пустой таблицы, в лог упадет запись SQL_CODE=100, Row not found to truncate. Обернуть каждый truncate в условие, - в теории можно, но хотелось бы понять, что не так. Как сделать чтобы warngings просто игнорировались? Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 17:32 |
|
AS400 DB2, errors handling
|
|||
---|---|---|---|
#18+
McCar, Добрый день. NOT FOUND и SQLWARNING conditions не одно и то же. См. handler-declaration в описании compound-statement . Не хотите ловить NOT FOUND - уберите ", NOT FOUND" из "DECLARE EXIT HANDLER". ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 22:43 |
|
AS400 DB2, errors handling
|
|||
---|---|---|---|
#18+
Mark BarinsteinMcCar, Добрый день. NOT FOUND и SQLWARNING conditions не одно и то же. См. handler-declaration в описании compound-statement . Не хотите ловить NOT FOUND - уберите ", NOT FOUND" из "DECLARE EXIT HANDLER". Хм.. точно.. Я был настолько уверен, что "NOT FOUND" - это когда обращаешься к несуществущему объекту, что даже не связал текст Warning-а при Truncate пустой таблицы и "NOT FOUND" в определении handler-а. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2019, 20:50 |
|
AS400 DB2, errors handling
|
|||
---|---|---|---|
#18+
McCar, А вообще код обработчика написан странно. Навряд ли тот, кто его разрабатывал, хотел получить такую логику. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Несколько проблем: 1. Команду GET DIAGNOSTICS надо выполнять первой в блоке обработчика. Связано это с тем, что в отличие от остальных команд, в т.ч. и SET, ее выполнение не приводит к неявной установке переменных SQLCODE и SQLSTATE. В коде выше после того, как выполнена команда SET SQLCODE_EXCEPTION=SQLCODE, командой GET DIAGNOSTICS уже не поймаешь сообщение об ошибке. Она получает сообщение о предыдущей выполненной команде, в данном случае - SET, которая выполнится успешно. Т.е. SET и GET DIAGNOSTICS надо поменять местами. 2. Сообщение появится в таблице FSTEST01.BUILDLOG_ERRORS только если в приожении (процедуре), вызывающей эту, в ответ на RESIGNAL будет делаться COMMIT. Иначе вставка в эту таблицу откатится вместе с остальными изменениями в этой транзакции. если в вызывающем приложении делается ROLLBACK в ответ на этот сигнал. В IBM i 7.2 появились автономные процедуры, которые можно использовать для такого журналирования. Т.е. в обработчике можно вызвать такую процедуру, объявленную как autonomous, которая выполняется в своей транцакции, на которую не влияет вызывающая транзакция. И уже в этой процедуре делать INSERT INTO FSTEST01.BUILDLOG_ERRORS. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2019, 21:32 |
|
|
start [/forum/topic.php?fid=43&fpage=4&tid=1600227]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
others: | 319ms |
total: | 429ms |
0 / 0 |