Добрый день, уважаемые мастера. Вопрос к знатокам MSSQL.
Имеется хранимая процедура на сервере. Для простоты сократим код до такого:

SELECT * FROM MyTable
RAISERROR('Ошибка',16,1)

В этом случае в клиентской программе исключения не возникает. Изменим процедуру:

RAISERROR('Ошибка',16,1)
SELECT * FROM MyTable

Теперь все нормально. Подключаюсь к серверу через ADO. Проблема, как я понимаю, известная :
http://www.delphisources.ru/pages/faq/base/bde_sql_links_questions.html
см. пункт 9.
Теперь вопрос - кто-нибудь может обойти эту проблему? Можно ли сбросить результаты внутри ХП?

> В этом случае в клиентской программе исключения не возникает.


1. Проверь все рекордсеты, которые тебе пришли. Первым твой селект пришёл, а вот вторым, скорее всего - error.
2. А нафига какие-то действия в хп после выполнения выходного селекта? Вот хоть убей меня - не пойму.

> 2. А нафига какие-то действия в хп после выполнения выходного
> селекта? Вот хоть убей меня - не пойму.

Это для простоты так написал. Тоже самое при любом операторе UPDATE, DELETE и т.п.


> 1. Проверь все рекордсеты, которые тебе пришли. Первым твой
> селект пришёл, а вот вторым, скорее всего - error.

А почему исключения не возникает?

> Это для простоты так написал. Тоже самое при любом операторе
> UPDATE, DELETE и т.п.


А ты Set NoCount On включи.

Моё глубокое ИМХО: я ещё пока не встречал задачи, где в хранимке raiserror был нужен.

Ega23, спасибо! При открытии следующего RecordSet с ошибкой - вылетает исключение.

> Моё глубокое ИМХО: я ещё пока не встречал задачи, где в
> хранимке raiserror был нужен.

ИМХО обычное дело - например при откате транзакции выдать клиенту сообщение о неудавшейся операции

> ИМХО обычное дело - например при откате транзакции выдать
> клиенту сообщение о неудавшейся операции


Замечательно. Только это всё и без raiserror можно сделать.

> alexnmsk  (27.11.2008 10:16:00)  [0]

А нафига ты используешь БДЕ

> А нафига ты используешь БДЕ


А нафига ты используешь MS SQL?

> А нафига ты используешь MS SQL?

Вот с этого и надо начинать :)

> [3] Ega23 ©   (27.11.08 10:52)

Олег, как не встречал? Да на каждом шагу оно, когда проверяешь корректность ввода, или целостность данных при каком либо расчете.

> когда проверяешь корректность ввода, или целостность данных
> при каком либо расчете.


Я, как бы такие вещи ДО момента записи в БД проверяю обычно...

> Я, как бы такие вещи ДО момента записи в БД проверяю обычно.
> ..

ДО - оно в многопользовательском режиме не всегда помогает.

> ДО - оно в многопользовательском режиме не всегда помогает.


Я вот как-то однопользовательские режимы и не делал никогда.

> [10] Ega23 ©   (03.12.08 17:29)

ну есть разные пути. То с чем я работаю - вся бизнес-логика в ХП упакована.
Опять же все проверки это гора трафика между клиентом и сервером.

> Опять же все проверки это гора трафика между клиентом и
> сервером

так уж и гора?
а кидать исключения клиенту с сервера - не трафик?

> а кидать исключения клиенту с сервера - не трафик?


Вот-вот. И потом - по новой хп запускать.

> [14] clickmaker ©   (04.12.08 14:14)

Намного меньшая.
для сравнения при импорте биржевой сделки проверяется наличие и сответствие примерно 15-20 различных параметров

как это выглядит в описанном Олегом виде
1.прочитали строку
провели 15-20 проверок (запрос-ответ)
если все проверки пройдены
 то произвели импорт записи
перешли к 1

в моем случае
1.прочитали строку
отдали серверу
 если возникли ошибки вернули райзерор
 иначе вставили запись
перешли к 1

итого в первом случае мы по каждой записи гоняем 15-20 конструкций запрос-ответ.
Есть подозрение что кроме роста трафика это сильно увеличит время исполнения (именно на сетевой обмен)

> [15] Ega23 ©   (04.12.08 14:34)

А это как эти исключения ловить...

> итого в первом случае мы по каждой записи гоняем 15-20 конструкций
> запрос-ответ

зачем? можно сразу все проверить

> [18] clickmaker ©   (04.12.08 14:41)

точно? ну можно попробовать

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

что в ХП что на клиенте делаем эти надцать запросов и потихоньку клеим строку ошибок
если делаем на клиенте то + время сетевого обмена и + сетевой трафик на каждую проверку

вот я и посмотрел бы на один запрос это делающий
по сути можно. тогда это таже ХП получающая тот же наборо данных
то есть алгоритм преображается в
запустили ХП проверки с полным набором данных
получили ответ
проанализировали оный
по результатам запустили ХП денйствие, с полным набором данных
итого набор данных  (для ММВБ это 22 или 33 поля) гонялся к серверу 2 раза то есть время одного прогона запрос-ответ явно лишнее.

> [19] Павел Калугин ©   (04.12.08 14:54)

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

> [21] clickmaker ©   (04.12.08 15:00)

естественно имеют
прользователь должен сразу видеть в чем лажа
иначе он будеит 15 -20 раз капу давить получать очередной отлуп и кричать "что за б..я система"

> провели 15-20 проверок (запрос-ответ)


Зачем?????

И потом - зачем именно Exception возвращать?

> > ДО - оно в многопользовательском режиме не всегда помогает.
>
>
>
> Я вот как-то однопользовательские режимы и не делал никогда.
>

А я не писал, что проверки ДО - это совсем плохо. Просто иногда - бессмысленно.

Самое простое - проверка на уникальность. Если проверять селектом ДО вставки, то никто не гарантирует, что за время между проверкой и вставкой никто дублирующую запись не засунет. А эксепшион - он завсегда вылезет.
Другое дело, что в случае T-SQL выполнение хранимки, скорее всего при этом не прервется . . .