Грабли DBIные, заботливо присыпанные листвой

[dil]

Ну конечно, я на них наступил.

Типичная последовательность действий при работе с базой данных: prepare(), execute(), если надо прочитать результат – fetch(), ну и в конце finish(). И до сих пор всё работало.

И тут ВНЕЗАПНО оказалось, что если выполняется не обычный SQLный оператор, а хранимая процедура (посредством EXECUTE PROCEDURE), то возникшая при выполнении ошибка после execute() никак не проявляется. Типа, всё нормально выполнилось. А вот когда потом делаешь fetch(), тут-то ошибка и вылезает. Более того, если процедура ничего не возвращает, то ошибка не проявляется вовсе. И процедура, кажется, вообще не выполняется, пока не сделаешь fetch(). Да-да, fetch(), который заведомо ничего вернуть не может.

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

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Comments

Re: это баг DBI ?

[kranov.livejournal.com]

В описании процедуры слово RETURNING есть или нет?

Re: это баг DBI ?

[dil.livejournal.com]

Нет, а то б она была функцией.
В моём случае возвращать ей нечего, она добавляет запись в таблицу, предварительно проводя некоторые логические проверки, не реализованные на уровне constraint'ов. Если какие-то проверки не прошли, генерирует ошибку.