Есть ХП, которая создает курсор, с помощью которого модифицирует таблицы. При выходе из ХП необходимо курсор закрыть. Т.е. автоматически это потеря кода ошибки. Что в случае нормального завершения (здесь нет проблем, код все равно равен 0), что в случае возникновения ошибки.
Сохранение sqlca.sqlcode и восстановление его после закрытия курсора не помогает, очевидно надо сохранять всю структуру sqlca, собственно это логично. Другой вариант - возвращать код в виде выходного параметра.
Может быть есть какой то более цивилизованный (правильный) способ?
Вот примерный код:
Если строку /* 1 */ убрать, то возвращается ошибка с кодом 464.
Доки пока ничего не дают, вроде написано все корректно, с точки зрения ограничений на ХП.
Решение найдется, хотелось бы понять, может я что-то неправильно делаю?

Mark Barinstein1.
SQL0464W - это не ошибка, а предупреждение.
2.
Код ошибки (или sqlstate) можно (и я считаю, что нужно) возвращать в выходном параметре.
1. Да, 4 глаза не помогли 8) (очки)
Выводы следующие:
1. Возвращать sqlcode как параметр и его анализировать. (Сейчас анализируется "штатный" sqlcode, а он "кривой"). Получилось нормально, работает.
2. Аналогично, возвращать sqlstate. Пока есть несуразности, сейчас разрулю.
Спасибо за мысли :)

ппмimho declare condition с последующим signal этого condition более понятно.
Или я чего-то не понял.
Я Ваше сообщение видел, но пока не проверил, а потому не ответил.
Работы как всегда выше крыши, да еще постоянно отвлекают. :) :(

ппмimho declare condition с последующим signal этого condition более понятно.

Собственно у меня есть хранимая процедура внешняя, написанная на С. Как в ней использовать SIGNAL и иже с ним не понятно.
Обработчик ошибок у меня и так есть, декларирование здесь:
Обработка, собственно на метке error_exit .
Поэтому сигналы (я имею в виду команду SIGNAL) здесь не нужны, ведь я знаю код ошибки в обработчике и могу его сохранить, передать как выходной параметр.
2 Mark Barinstein :
Я нашел в примерах SQLLIB использование курсора во внешней ХП, там они курсор просто не закрывают. Мысль понятна, поскольку курсор закроется при ROLLBACKе. Думаю, что у них тоже не все чисто, sqlstate затрется, сейчас проверю.

ппмпередать как выходной параметр - это одно.
Но ведь вы получили sqlcode и sqlstatem,
а прользователю "подсовываете" осетрину второй свежести - выходной параметр.

Почему бы и ему не вернуть sqlcode и sqlstate с помощью declare condition & signale <condition> set text, например.
Тогда ваш пользователь тоже получит "нормальную" ошибку.

Это, видимо, вопрос личных предпочтений.
Я понимаю о чем Вы, в конечном итоге, возможно, выходной параметр отпадет сам собой, поскольку будет не нужен. Я согласен, что способ с выходным параметром не достаточно красивый.
Посмотрим полный текст обработчика:
1. Здесь sqlcode & sqlstate в чистом виде уходят в вызывающую программу.
Какой смысл добавлять сюда еще что-то?
2. Не уверен, что EXEC SQL SIGNAL ... можно использовать во внешней ХП, поскольку такая ХП всегда завершается командой return ... в доках по этому поводу не очень адекватно. Даже если это возможно, предполагаю, что SIGNAL вернет только sqlstate, но не sqlcode.

ппмнасколько я помню, есть sample внешней SP с SIGNAL.
А по поводу что она вернет - гадать не надо, дока достаточно полно определяет
http://publib.boulder.ibm.com/infocenter/db2luw/v9//topic/com.ibm.db2.udb.admin.doc/doc/r0004232.htm

If a SIGNAL statement is issued, the SQLCODE returned is based on the SQLSTATE as follows:

* If the specified SQLSTATE class is either '01' or '02', a warning or not found condition is returned and the SQLCODE is set to +438.
* Otherwise, an exception condition is returned and the SQLCODE is set to -438.


Пойдёт это вам или нет, смотрите.
Отсюда видно, что исходный sqlcode будет утерян, увы.

Пробовал я убрать закрытие курсора в случае ошибки, увы, сбрасывается и sqlstate и sqlcode, поскольку возвращает Warning с SQLSTATE 464.

Все таки если хочется корректного sqlcode & sqlstate, придется возвращать их в выходных параметрах. Просто будет стоять проверка, если стандартный sqlcode 0, то проверять тот, что вернула ХП.
Особенно важно это пока не отлажена ХП, потом будет проще, хотя для быстрого поиска ошибок знать конкретные sqlcode & sqlstate очень важно и в процессе эксплуатации программы.

Nikolay KulikovRESIGNAL?
Если использовать эту технологию, то согласен, это было бы то, что надо. RESIGNAL без параметров.

Но вопрос останется, как не крути, если курсор закрыть, то sqlca изменится, а если не закрывать, то sqlca все равно изменится :)
Куда не кинь - всюду клин.
Сегодня точно добью конечный вариант с возвратом кода и статуса ошибки в виде выходных параметров. Это и будет окончательный вариант.

ппмну это же типичный случай, даже если взять вот за пример вывод сообщений об ошибках db2,
зачастую идёт сообщение с одним SQLSTATE, внутри него сообщение с другим SQLSTATE sqlcode, а в нём может быть вложенное еще одно.
Вкладывайте на здоровье, используя text messages.
RESIGNAL может быть использован только в SQL procedures , в external SQL procedures он использоваться не может. Взято из таблицы 5 (страница 55) файла с1043730.pdf ("Developing SQL and External Routines").
SIGNAL аналогично, но он может дополнительно использоваться в SQL functions.

Самое прикольное я тут столкнулся с проблемой, что у меня в случае ошибки в этой ХП, OUT параметр не возвращается, хотя в логах моих все ок. Уже доки изрыл, но нигде про такое не написано.
ESE 9.1.3 for Windows.

А по существу дела да, sqlcode не возвращается, я его сунул сюда пока:

sprintf(SQLUDF_MSGTX,"%d: ",sqlca.sqlcode);
strncat(SQLUDF_MSGTX,sqlStmtInfo,60);
SQLUDF_MSGTX[59] = '\0';

А вот SQLSTATE нормально возвращается, даже если закрывать курсор, что я сейчас и делаю.