Вышел 9.0.2.3274. А баг все там же

ASCRUS Александр ГoлдунВышел 9.0.2.3274. А баг все там же
Ну они же отписали, что типа багом не считают, но в саппорт передадут. Значит ждать не скоро придется.
Тем не менее, они кажется твою и интерпретацию все-таки подправили. Т.е. тот самый OOPS уже не выводится в консоли. Но ISQL все равно не ругается, хотя должен.
Кстати, а какой номер у твоего кейса был? Вот что в readme нашел:

(Build #3266 - Engineering Case #421675)
Interactive SQL would not have consistently reported errors raised from within
a stored procedure if connected via jConnect. This has been fixed.

Говорят, что фиксед, а он все равно не ругается. Сверь, не твой ли это кейс, может они отмазались?

Блин, они так и не поправили этот баг, уроды! Мы уж и BDE на ADO сменили, и mixed dialect убрали - один хрен, не доходят ошибки до клиента, если вызов SELECT имяфункции, хотя при использовании CALL имяфункции эксепшн нормально доходит до клиента.

ASA 9.0.2.3496

МарсельА вы пробовали воспроизвести им баг на SA10 или SA11 beta?

Когда-то давно пробовал на ранних SA10 - не воспроизводилось. Сейчас не знаю, не имею пока установленных SA10.

Я фигею с них. Сделал полностью воспроизводящий ошибку скрипт. Отправил в форум:
http://groups.google.com/group/sybase.public.sqlanywhere.general/browse_thread/thread/cc84998367eba505/eeeddc65e6af1cb6?lnk=raot#eeeddc65e6af1cb6
На что получил там же ответ от Nick Elson, что оказывается это нифига не баг, и что exceptions предназначены только для процедур и триггеров, а не для функций. Типа функция должна всегда возвращать значение, а для искличительных ситуаций надо использовать специальные возвращаемые значения, например NULL.

Не, ну не маразм разве?

Такое ощущение, что я здесь единственный, кто активно использует SQL-функции.
Кто-нибудь еще использует raiserror или signal в функциях?

Марсельraiserror использую, signal - нет

Ну, собственно с raiserror это и началось 2 года назад. Но тогда они наехали, что это типа mixing dialekt и они за себя не ручаются в таком случае.
Марсель
в процедурах, функциях, тригерах ...
клиент (d7, dbexpress) ошибку ловит.

Так вот, то что оно ловит, это по их мнению side effect, undocumented feature и в будущем этот behavior может быть changed. Может я туплю или чего-то недопонимаю? Перерыл доку. Функции - подкласс процедур. Никаких ограничений на использование исключений для них нет. Ну и как им это доказать?

antand iLLer RAISEERROR'ами пользовался в процедурах. В функциях - нет. Вроде смысл у них
и впрямь разный.

Аналогично. Как-то даже мысли и потребностей не возникало в функциях этим пользоваться.
Мое мнение - функция должна возвращать результат вычислений. Если он не вычисляется на основе исходных данных, то можно вернуть пустой(неопределенный) результат, null. На выходе ведь всегда можно его проанализировать.
Хотя может у Александра задача какая-то специфичная и без этого никак.
Странная логика. Задача обычная. Без исключений, конечно, можно обойтись, но зачем, если с ними гораздо лучше? Вон в некоторых серверах вообще нет такого понятия, как SQL-функции - и ничего, обходятся как-то же! Но мы ж наверное и используем ASA, а не Firebird к примеру, в том числе и потому что есть много удобных возможностей.
Есть удобный механизм обработки исключительных ситуаций. И не важно, процедура это или функция, почему должна быть разница? А возврат свецзначения, как советуют тут некоторые, а там Nick Elson, далеко не самое элегантное решение. Зачастую оно должно просто прервать выполнение, а не возвращать бред. Если например выборка в селекте несколько тысяч записей со сложновычислимыми полями, то зачем нужно тратить ресурсы и время на получение заведомо кривого результата, если в самом же начале можно получить исключение?

Впрочем, если кто следил за дальнейшим обсуждением по приведенной ссылке, то мог заметить, что там похоже поняли, что х-ню сморозили, к обсуждению подключился Chris Keating, который уже не высказывал подобного бреда. Вердикт такой: проблема в передаче ошибок на клиента, возможно в драйверах ODBC и ADO. Запрет исключений в функциях - лажа полная.