Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Sybase ASA 9. Всегда ли raiserror в триггере приводит к откату всего, что сделано в триггере и в операторе, который привел к срабатыванию триггера ? Хочется, чтобы сообщение об ошибке на клиента ушло, но выполнение запроса не прерывалось. Это возможно ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:40 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
SET OPTION PUBLIC.CONTINUE_AFTER_RAISERROR = 'ON' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:17 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
"Выполнение запроса не прерывалось"- я имел в виду, чтобы не происходил откат всех изменений, которые сделал триггер и то действие, которое этот триггер запустило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:29 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Писать под ODBC перехват MESSAGE TO CLIENT, воспользоваться saVCL и по любому отказаться от этой идеи в таком виде реализации ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:46 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
LercheХочется, чтобы сообщение об ошибке на клиента ушло, но выполнение запроса не прерывалось. Это возможно ? А ничего типа print в ASA разве нету? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:16 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Print нетУ, зато есть Insert into. Заведите журнал(таблицу) процессинга и туда триггером пишите измышления вашей системы по поводу происходящего...) RaiseError - носит не уведомительный характер, а критический с точки зрения СУБД для вашего клиентского ПО. Поэтому им уведомлять клиента неправильно. А писать всякие уведомлялки с использованием ОДБС - тоже верх безрассудства. СУБД по определению является пассивным элементом системы, а клиент - активным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:27 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:59 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
iLLerPrint нетУ Вообще-то, print есть. Печатает любой текст в окно сервера. Во вторых, есть команда message, почему использовать ее "верх безрассудства" не понимаю. В третьих, действительно есть универсальный для всех типов серверов "insert into SomeMessageTable". iLLerRaiseError - носит не уведомительный характер, а критический с точки зрения СУБД для вашего клиентского ПО. Поэтому им уведомлять клиента неправильно.Уведомлять о достижении промежуточного чекпоинта в процедуре - действительно неправильно. А вот о критических проблемах - самое правильное :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 17:56 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Расскажу в чем идея была: Есть некая клиентская оболочка, для внесения всяческих изменений в БД вызываются различные процедуры, какие внутри них апдейтятся таблицы, оболочка не знает. Есть в системе аудит операций, построенный на триггерах. Т.е. пользователь в клиентской оболочке напротив определенной таблицы (вернее даже полей таблиц) ставит галочку, при этом создается триггер, который начинает отслеживать все транзакции и сохранять их в журнал. Теперь появилась потребность при изменении определенных таблиц запрашивать причину изменения у пользователя оболочки. Что хотели сделать: в журнал операций добавляется поле "Причина", в настройках аудита добавляется еще одна галочка на каждую таблицу "Указывать причину". Клиентская оболочка не знает какие таблицы будут модифицироваться внутри процедуры и нужно ли по ним запрашивать причину изменения и заранее не может потребовать от пользователя ввести причину модификации данных. Думали, что триггер, в момент срабатывания посмотрит, нужна ли причина, если да, то он вставит запись в журнал операций, вызовет определенный raiseerror и в нем передаст клиентской оболочке ID вставленной записи в журнал операций. Оболочка обработает exception, увидит определенный номер, вызовет еще одно окошко, в котором попросит пользователя ввести причину и вызовет процедуру, которая проапдейтит журнал операций, вставив туда причину модификации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 10:28 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
VovakaДумали, что триггер, в момент срабатывания посмотрит, нужна ли причина, если да, то он вставит запись в журнал операций, вызовет определенный raiseerror и в нем передаст клиентской оболочке ID вставленной записи в журнал операций. Оболочка обработает exception, увидит определенный номер, вызовет еще одно окошко, в котором попросит пользователя ввести причину и вызовет процедуру, которая проапдейтит журнал операций, вставив туда причину модификации. То есть, внутри транзакции ожидается ввод пользователем причины, и пока ее юзер не введет, транзакция не завершается? Тогда Вам в форум "Проектирование" надо, а не сюда :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:43 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов То есть, внутри транзакции ожидается ввод пользователем причины, и пока ее юзер не введет, транзакция не завершается? Тогда Вам в форум "Проектирование" надо, а не сюда :). Нет, транзакция не должна откатываться, стоит опция "Продолжать после ошибки", но в ASA, если это произошло в триггере, все равно идет откат, в ASE и в MSSQL - работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 14:45 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Идея в том, что просто нужно уведомить клиентскую оболочку о неком событии из триггера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 14:50 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
VovakaИдея в том, что просто нужно уведомить клиентскую оболочку о неком событии из триггера Володь, а что тебе правда не понравилась идея с табличкой. Сделай глобальную времянку, с очистой по COMMIT, вызываешь с клиента сохранение данных, если нужны уведомления, триггера пишут в эту времянку, клиентское приложение при неудачном сохранении делает ROLLBACK, при удачном считывает табличку и делает COMMIT. Дальше по рекомендациям в табличке делает что нужно. По моему вполне компромиссный вариант, хотя я все равно против такой постановки именно самомо вопроса ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 15:21 |
|
||
|
raiserror в триггере
|
|||
|---|---|---|---|
|
#18+
Есть предложение: раз модификация таблиц идет из хп, а не напрямую, то и логировать в журнал можно/нужно из хп. И причину нужно передавать на вход хп вместе с данными. Тогда это будет одна транзакция, тогда это будет технологичней. И диалог с запросом на причину клиентское ПО должно показывать до вызова хп. Если заранее неизвестно нужно ли показывать диалог с предложением ввести причину, то предлагаю ввести промежуточный уровень, выраженный к примеру, ввиде хп, которой на вход подаются теже данные, что и на вход основной хп, а на выходе она сообщает необходимо спрашивать причину или нет. Тогда вся цепочка действий будет состоять только из атомарных вызовов хп и работа СУБД связана с работой клиента штатным технологией "запрос-ответ". "Пользователь ввел данные, нажал кнопку сохранить"->"клиент дернул процедуру спросить_ли_причину(...)"->"сервер ответил спросить"->"клиент выкидывает юзеру вопрос"->"юзер ковыряет в носу"->"юзер сходил покурил"->...->"юзер указал причину"->"клиент дернул процедуру проапдейтить_все_нафиг(...,причина_такая_то)"->"сервер выполняет процедуру"->"процедура записала в журнал все необходимые отметки". P.S.: Проектировать надо лучше. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 23:12 |
|
||
|
|
start [/forum/topic.php?desktop=1&fid=55&tid=2013015]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
43ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 250ms |
| total: | 379ms |
| 0 / 0 |
