Ну конечно, я на них наступил.
Типичная последовательность действий при работе с базой данных: prepare(), execute(), если надо прочитать результат – fetch(), ну и в конце finish(). И до сих пор всё работало.
И тут ВНЕЗАПНО оказалось, что если выполняется не обычный SQLный оператор, а хранимая процедура (посредством EXECUTE PROCEDURE), то возникшая при выполнении ошибка после execute() никак не проявляется. Типа, всё нормально выполнилось. А вот когда потом делаешь fetch(), тут-то ошибка и вылезает. Более того, если процедура ничего не возвращает, то ошибка не проявляется вовсе. И процедура, кажется, вообще не выполняется, пока не сделаешь fetch(). Да-да, fetch(), который заведомо ничего вернуть не может.
В документации, естественно, эта замечательная особенность не описана. И я, как обычно, на эти грабли наступил и потратил полдня, чтоб понять, какого хрена оно молча не работает.
Оригинал этой записи. Комментировать можно тут или там.
Re: это баг DBI ?
В общем-то им даже проще, предполагается что есть два типа sql, возвращающие курсор и не возвращающие, поэтому первые вызываются sql.open а вторые sql.exec. Первые всегда фетчатся вторые никогда, правда они проверяют все равно вернулся курсор или нет.
Re: это баг DBI ?
Re: это баг DBI ?
Re: это баг DBI ?
В моём случае возвращать ей нечего, она добавляет запись в таблицу, предварительно проводя некоторые логические проверки, не реализованные на уровне constraint'ов. Если какие-то проверки не прошли, генерирует ошибку.