Ситуация:
PB 10.5.2 Build 7611
MS SQLServer 2000

DataWindow построенно на хранимой процедуре. В поцедуре есть бизнес проверки, которые инициируют в ряде случаев ошибку (raiserror). Собственно я привел пример - маленькую процедурку, эмулирующую эту ситуацию, т.е. передал ей 'Y' она ругается, нет - возвращает resultset

CREATE PROCEDURE _test
@raiseerror_f CHAR(1) = 'N'
AS
BEGIN
DECLARE @err_msg VARCHAR(255)

IF @raiseerror_f = 'Y'
BEGIN
SELECT @err_msg = 'все плохо!!!'
GOTO ERROR_EXIT
END
ELSE
SELECT name_alt FROM account_type_c

RETURN 1
ERROR_EXIT:
RAISERROR 13001 @err_msg

RETURN -1
END
GO

GRANT EXECUTE ON _test TO public
GO

Так вот, в случае ошибки PowerBuilder должен вернуть в sqlerrtext строку "все плохо!!!", но вместо этого возвращает: Database error code: 999 Select error: Requested resultset number 1 not found."

Я поверил эту ситуацию на PowerBilder 6.5 - он ведет себя правильно, возвращая действительное описание ошибки.
Если на PowerScript`e написать embedded sql код, то все работает, но обычное DW на хранимой процедуре при вызове банального retrieve() ведет себя таким странным образом. Руками релизовал "ручной retrieve" через событие SQKPreview подменив вызов процедуры для получения resultseta через embedded sql код с ручной обработкой ошибки и ее инициализации и в случае отсутствия оной fetch для заполнения DW с отключенной на время отрисовкой ... но это МАРАЗМ. Я работаю с PB с 3-й версии и такой ошибки я не встречал. Звонил в Московский Сайбейс ... пока на работе уточняют покупали ли мы тех поддержку в нем пишу сюда, своим коллегам. Если даже техподержки нет, имхо сайбес обязан выслушать и записать данные о баге с последующим обещанием поправить в следующем EBF иначе это как покупка чайника. который неработает и который вообще говоря моэно вернуть продавцу... ладно, мне все равно. я обошел проблему на уровне предка написав код, но вообще я в шоке от таких ляпов.

Посмотрите ... что скажете? Что посоветуете? ...

Кто как выкручивается из этой ситуации?
Подтвердите мне, что я не одинок с этой проблемой

Т.е. я не одинок? Так как вы тогда живете то? Или все пишут несерьезные приложения? ... ( постите - никого не хочу задеть этой фразой)

Дарю изящное решение, код dberror:


Пока не скажу, что это подойдет во всех без исключения случаях. Но для приложения отчетов. кои я сейчас ковыряю, вполне проходит. У меня все отчеты имеют общего предка, так что поместив в его DW код на dberror я покрываю ошибку и могу принимать из базы верные сообщения об ошибках (мне это неорбходимо, например, выдавая сообщения "Отчет не может быть сформирован на дату позднее чем дата закрытия баланса по информационному регистру" ... кто в теме - поймет, кто нет, смысл тоже ясен.

Я уже писал, что я реализовал обход в SQLPreview, но он плохо поддается универчальному написанию кода, сейчас я передлал на dberror/ тот что привел.


Я на верном пути? Скажите честно - этот баг не только у меня (нужно торговаться с Сайбесом, во благо нас всех, чтобы пофиксили ... суки ... простите ...)

несколько слов покомментирую насчет: mid(sqlsyntax, 2) в пред.примере кода
Билдер зачем то передавая параметр в событие ставит единичку вначале sqlsyntax. типа "1 execute( ...." я ее обрезаю. Учитывая, что у меня все отчеты на хранимках, меня это устраивает, на DW построенных на чистых select`ах не проверял пока, можете сами поверить, но с другой стороны ошибка в отлаженом селекте это совсем другое дело и другая ошибка ... потому можно не заморачиваться, если свалится по причине ... какой нибудь причине.

Локшин Марк PavelBuilder Посмотрите ... что скажете? Что посоветуете? ...
На 9 такого нет. Можно попробовать после (или перед???) RAISERROR вернуть пустой select такой же по форме, который ожидает DataWindow - IMHO должно сработать, но это же везде менять нужно, так что в предке наверное лучше, но опять же если данных много...

Марк, я пробовал. Билдер тогда не сообщает об ошибке ничего. Т.е. он наедается тем, что резатсет есть и молчит в тряпочку, зажимая сообщение по raiserror. Т.е. попросту он банально не обрабатыавет сообщение об ошибке по raiserror и ругается на то что нет резалтсета, которого и быт не может в случае ошибки, а если все же дать ему его ... см. я писал в пред. преждложении :-)

Dim2000
PavelBuilder wrote:

> Так как вы тогда живете то?

Замечательно . Кто как, а я не возвращаю ошибок из процедур.
Posted via ActualForum NNTP Server 1.4

Значит вы не пишите процедур. Любая процедура предполагает некие действия, которые могут быть выполнены или могут быть не выполнены (например, вы подошли к банкомату вставили карту, указали сумму и ждете денег, итог: или вы снимаете деньги с карты и получаете деньги или все остается как было, помежуточного состояния быть не может(деньги с карты сняты, а денег не дали ил наоборот). Это называется "транзакция" (не транзакция в базе данных, хотя смысл схож) И несообщить об ошибке попросту нельзя) Пример не мой, я работаю с ценными бумагами(депозитарий), но по сути очень похоже.

Локшин Марк PavelBuilderТ.е. я не одинок? Так как вы тогда живете то?
Лично я такой ошибки не видел. А если сменить способ подключения к БД, (ODBC-OLE DB или наоборот) то проблема остается?

Соединяемся конечно через OLE DB, даже если через другой тип соединения будет иначе это не выход из решения проблемы (нужно пользоваться oledb, тут возражений нет?)
На PB 6.5 проверял и писал - проблем нет, Вы подтвердили, что с девяткой тоже нет проблем, но мы уже соскочили с нее ...

Попробовал ошибку с уровнем 19 (в серверный лог записалась!), больше не стал, на результат не влияет, Билдер ее не выводит. Так что похоже дело не в этом. А вообще, я не знаю людей, которые бы пользовались этими severity

ошибка в приведенном мной выше примере:
вместо "if itr_object.SQLDBCode > 0 then "
должно быть "if SQLDBCode > 0 then "

Пока остановился на этом ... ужастно конечно ...

edmikecaPB 9.0.1, работаем через ODBC, процедура в случае ошибки делает:

RAISERROR(@Err_Mes, 16, -1)

и в PB этот message прекрасно отображается.

Как я уже оговорился мы не пользуемся северити и сервер по умолчанию выставляет 16, так что что у меня, что у Вас вызов ошибки равноценен.

ODBC непримлима для работы ... даже обсуждать не хочется ... удивляюсь, что еще кто то пользуется пободного рода соединениями с базой.

Я попробовал северити 19 и результат тот же (я писал). Если выставить выше, то в случае ошибки сервер разорвет соединение(!), что просто неприемлимо - это обычная рядовая ситуация. Так что даже если гипотетически представить, что Билдер вернет мне сообщение об ошибке с уровнем от 20, то смысла в его выводе и обработки мне никакого, поскольку на этом приложение разрывает связь с сервером и в итоге приложение закрывается .... а надо то всего навсего сообщить о невозможности получения отчета в данный период (после ряда действий другого менеджера не закрывая приложения данный менеджер выполнит повторное нажатие кнопки получить и отчет будет доступен).

Так что не severity дело.

Ну и конечно прошу обратить на мою версию Билдера (см. первый пост .... возможно дело только в этом)

Отписал баг в Sybase, уже ответили, что проблемой занимаются и свяжутся со мной позднее.

Ну что ж я буду только рад, если помогут.

Проблема разрешилась:

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

Во-вторых: нельзя устанавливать на клиенте "SET NOCOUNT ON" иначе даже выполнив пункт первый ошибка останется. В программе выставили этот SET по совету админа, а вышло оно боком вот так. Похоже Билдер использует инфу о количестве обработаных строк, что ему возвращает сервер, а в случае SET NOCOUNT ON этого не происходит.

Примечательно что на 6.5 версии не требуется выполнение первого пункта, насчет второго не скажу (проверяли только в дизайн-тайме)

Так что имейте ввиду, может кому пригодится ...