У кого установлен ASA 9.0.2.3249, проверьте плиз такое:
Что происходит при вызове:
SELECT DBA.TestBug()
и при таком:
CALL DBA.TestBug()

ASCRUSПоведение такое же, как и на 3267:
1. В случае SELECT-а ошибка возвращается на клиента, как и пустой набор данных.


Не понял. У меня при селекте молча возвращает бред. Причем на версии 3137 корректно отрабатывается - ругается как положено. Проверил на двух инсталляциях 3249. Кроме того такое же бредовое поведение на 3228.

Маленькое дополнение. Подобный бред я наблюдаю при выполнении запроса
через ODBC+BDE, например из SQLExplorer или из своего приложения на
Delphi. При попытке выполнить такой SELECT через ISQL - нормально
заругалось. Куда копать, ибо такое поведение крайне неприятно.
Posted via ActualForum NNTP Server 1.3

Похоже на это:

================(Build #3143 - Engineering Case #392484)================

If an application using either the ASA ODBC driver, or the iAnywhere JDBC
driver, fetched a set of rows in which one of the rows encountered a data
exception, then it was likely that the error would not have been reported.
Note that Prefetch must have been on for the problem to occur. This problem
has now been fixed, but in addition to this change, the changes to the server
for Engineering Case 395662 are also required

Скачал EBF 3267, сейчас проверю

В 3267 та же задница. Чтобы исключить трабл с BDE попробовал из MSAccess
через ODBC - тоже молча возвращает бред.
Posted via ActualForum NNTP Server 1.3

ASCRUS пишет:

> данных. Причем, я подозреваю, что это баг, так как:
>
> CREATE PROCEDURE DBA.TestBug_Proc ()
> BEGIN
> SELECT DBA.TestBug();
>
> MESSAGE 'Полная жопа' TO CLIENT;
> END;
>
> CALL DBA.TestBug_Proc ()
>
> отработает полностью, даже с учетом того, что CONTINUE_AFTER_RAISERROR =
> 'OFF' , то есть процедура отработает неправильно.

Глянь плиз sybase.public.sqlanywhere.general и поддержи беседу, если
есть немного времени - у них что-то не получается воспроизвести на
бейсике через ODBC, а я по аглицки как собака - все понимаю, но
выражаюсь коряво и цейтнот сейчас небольшой - и так 3 часа убил уже на
эту засаду. Там свежая тема "New stupid bug in ASA 9.0.2.3249?"
Posted via ActualForum NNTP Server 1.3

> Глянь плиз sybase.public.sqlanywhere.general и поддержи беседу,

Там ни у кого не получается повторить ошибку. Кивают в сторону
смешивания мной диалектов. Уже даже Breck Carter подключился к обсуждению.
Posted via ActualForum NNTP Server 1.3

Рыжий Кот пишет:
> offtop, глюк, вызывающий исключительно заднефасадные впечатления

Вообще-то, хотелось нецензурное что-то написать, но удержался почти в
рамках приличия. Всегда работало, всегда на это полагался, а там мне
заявляют что оказывается я могу получить unexpected results по причине
mixing Watcom and TSQL dialect. И никто из участвовавших там в
обсуждении не смог воспроизвести это дело, а я проверил на 4 разных
серверах коннектясь с двух разных клиентских компов.

У кого-нибудь тут есть Delphi 6 или 7 и установленный ASA версии 3228
или 3249 или 3267?

Создайте плиз эту долбаную функцию в любой базе, хотя бы в asademo и
попробуйте выполнить SELECT DBA.TestBug() из SQLExplorer от Delphi.

Я один такой?
Posted via ActualForum NNTP Server 1.3

iLLer пишет:
>
> Это, походу дела, проблема клиента. Попробовал в isqlc, raiseerror
> вылазит в
> обоих случаях.
> Мне кажется, SQLExplorer банально игнорирует ошибку и все, а

isql и я пробовал. Можно было бы списать на SQLExplorer, а точнее на
BDE, если бы не 2 "но":
1. С версией 9.0.2.3137 все нормально работает
2. Таже самая фигня через MSAccess+ODBC - создал в нем 2 запроса к
серверу. CALL вызывает ошибку, SELECT тихо возвращает бред.
Когда в функции заменил raiserror на SIGNAL myexception, Access тоже
стал ругаться как положено. А через BDE опять фигня. Упоминалось, что у
них были какие-то изменения в механизме передачи ошибки, но детально не
разбирался.

Posted via ActualForum NNTP Server 1.3

ASCRUS пишет:
> Я же процедуру привел, которая выводит MESSAGE,

Придерутся, что SELECT DBA.TestBug(); не фетчится никем или что-то типа
того. Сделай присвоение куда-нибудь результата функции внутри этой
процедуры.
Posted via ActualForum NNTP Server 1.3

Марсель пишет:

> У меня D7.1 только я через dbExpress, ASA 9.0.2.3249
> Ошибка генерится и Call и Select'ом, ничего не возвращается

а через BDE и sqlexplorer?
Posted via ActualForum NNTP Server 1.3

White Owl пишет:
> Попробовал на 2451. Повторить не получилось. Работает как положено

Они это поломали где-то между 3137 и 3228. В первом все ок, во втором и
далее уже проблема. Сознаваться не хотят :)
Posted via ActualForum NNTP Server 1.3

ASCRUS пишет:
> Ответ с моего CASE:

А где ты кейсы выкладываешь? Я пробовал зайти на
http://case-express.sybase.com/ но у меня там в перечне Product/Product
Family почему-то отсутствует ASA, есть только Family 1,5,13-16,18,19
Posted via ActualForum NNTP Server 1.3

Вышел 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. Запрет исключений в функциях - лажа полная.