Всем доброго времени суток!

Собственно весь вопрос в теме.
Если чуть конкретнее - есть БД SQL Server и сервер GlasFish. В БД крутится триггер, который проверяет в одной из таблиц целостность данных при сохранении (кго алгоритм тут уж роли не играет). В случае неудачи транзакция откатывается.
И вот далее интересно:
Как донести инфу о том почему именно транзакция не свершилась клиенту?
1. Конкретно в MS SQL триггер может выдать методом PRINT сообщение, которое прочтет админ БД если ему сильно захочется поработать с базой напрямую - отпадает.
2. Я попользовался методом RAISEERROR, в которое упаковал сообщение - это оказалось ближе к истине. На сервере после flush этот exception и "лежащее" в нем сообщение ловятся, но довольно "некрасивым" способом. У меня (используется JPA) вышло так: „PersistenceException“ -> „DatabaseException“ -> „SQLServerException“ -> „Exception от триггера“ с сообщением через getLocalizedMessage().

Мне способ 2 НЕ нравится, просто я не нашел лучше. Может кто-то подсказать есть ли что-то более нативное для подобных целей?

Заранее спасибо!

П.С.: то что проверять можно на клиенте перед сохранением понятно. Как раз и хотелось бы "из спортивного интереса" попробовать получить универсальное решение со стороны самой базы чтобы потом уже с увеличением количества триггеров (а оно в небольшой степени будет в любом случае) не думать ни о чем.

вадя, с udf не сталкивался - посмотрю. Спасибо.

just_vladimir да реакцию нужна сразу. Клиент сохраняет изменения, которые триггер откатывает как невалидные. Конечно ему надо сообщить в чем дело без отлагательств. JMS - очень хорошая мысль. До ее реализации на сервере у нас еще не дошло, хотя это определенно придется сделать. То что MS SQL с ней дружит для меня новость - классно. Не знаю возможно позже я попробую именно этот метод реализовать. Отправлять же дополнительный запрос - ну наверное это можно сделать рабочим методом но по моим ощущениям это потребует больше "костылей" чем мои потуги с вытягиванием сообщения из эксепшена... Спасибо!

Petro123 RAISE "У клиента .... отсутствуют средства на счёте" из триггера - ну пока как-то так это и работает в тестовом режиме. Сообщения нужно делить на уровни. - вы имеете ввиду уровень эксепшена в самой БД? Это в триггере конечно делается. Я про "некрасивость" имел ввиду что мне упорно не нравится работать через эксепшены в принципе, да еще и приходится брать причину (getClause() если не ошибаюсь), причем ни один раз. Как-то это противит моему эстетическому чувству:)

Petro123, spring не используем - варианты с его аннотациями отпадают. Правильно ли я понимаю что так или иначе мне надо на уровне БЛ разбираться с исключениями, т.е. все же ничего адекватнее подъема исключения в самой БД (которое я перехватил на сервере) параллельно с откатом транзакции не имеется (даже если начать теоретически смотреть на Spring и AOP - все же они опять таки будут ловить это же самое исключение но пусть изящнее и проще)!? Тогда выходит что все то же и так же - я триггером откатываю транзакцию и поднимаю исключение - на сервере его ловлю (что мне кажется не оптимальным) и получаю пройдя через несколько "порождающих" исключений таки некое сообщение (или код - не суть), которое так или иначе уже шлю клиенту. Это до чего я сумел доскрипеть и что мне не понравилось (ну Ок - пусть мои сомнения живут и дальше в моей мятущейся и ищущей совершенства душе). Принципиально лучше ничего не существует? Нет библиотек которые могли бы нормально "обмениваться сообщениями" с базой и соответствующих методов "отправки сообщений" в самой БД? Мне идея подружить query notifications с JMS от уважаемого just_vladimir понравилась - возможно получится это реализовать, но не хочется лезть пока JMS еще вообще не заведена...

MasterZiv " сервер бд выдает стандартным средством ошибку с сообщением, по connectivity она летит клиенту СУБД, который есть твой Glassfish ". Так кто этот таинственный "стандартное средство"? У меня весь сыр-бор начался с его поиска и ненахождения. Я тут и пытаюсь узнать есть ли он вообще в природе. Есть?

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

ВАДЯ, да могу получить сообщение на сервере и дальше отправить клиенту. Просто то как я это делаю по-моему костыли, оттого и пытаюсь найти что-то более нативное.

Usman спасибо. Это интересно, но по-моему куда менее оптимально чем работа через эксепшены в данном случае. Нет!?

Petro123, матчасть подтягивать хочу, пытаюсь делать и буду и дальше пытаться! :)

Код:
еще раз о том что сие есть: Сервер - GlassFish. БД SQL Server. Клиент (хотя это тут не важно конечно) - десктопное приложение на JavaFX.
1. Вот что делает триггер (не "функциональные" части я опуская чтобы не засорять тут все рулонами кодов):


2. Вот как я ловлю это на сервере (опять же выдержки):

Usman понял спасибо!

Petro123:
1. отсылку сообщений можно убрать это не проблема. Я правда не понимаю чем это вредит, ведь на сервер они не приходят. По моему разумению это просто на тот случай если кто-то вручную поработать с БД захочет - с целью дать понять в чем дело.
2. "если вся бл триггерах и бд" - нет в БД только триггеры для проверки целостности данных. Основная логика уже на клиенах. Тут в примере просто сам сервер получает сообщение - отправить его клиенту (вместо null) это уже не проблема. Мне просто как раз и не нравится именно то место где я "докапываюсь" до сообщения от триггера...
3. Спасибо что тратите на меня столько времени:)

Petro123
1. Это конечно не "рабочее" решение. То что тут кидается на вывод в консоль - чисто для меня увидеть что да мол вот я это получил. Клиенту будет отправляться вместо null например JSON объект, в котором будет лежать сообщение (или его код), но там уже разные варианты как передать и тут как раз вопросов пока вроде нет.
2. Cервер - GlassFish. Я на нем хочу получить сообщение от триггера БД (что и делаю своим корявым способом), чтобы далее донести клиенту почему то что он хочет сохранить мы сохранять нифига не будем - ради этого весь сырбор. Касательно "Ошибка из триггера будет очень редко" я не согласен - будет столько сколько попыток будет сохранить неверные данные. Да хоть бы и редко - я хочу чтобы это работало! :) Как раз интересно иметь триггер который будет делать работу и на клиенте раз оно уже делается триггером не думать снова о проверках при сохранении. Я хочу просто получать ошибки уже из базы для конкретно этих случаев (проверяемых триггерами). Вот и пытаюсь найти универсальное и правильное что-то.
возвращаясь к моему вопросу
авторто что проверять можно на клиенте перед сохранением понятно. Как раз и хотелось бы "из спортивного интереса" попробовать получить универсальное решение со стороны самой базы чтобы потом уже с увеличением количества триггеров (а оно в небольшой степени будет в любом случае) не думать ни о чем.

Petro123,

зависит от БЛ. Приведи БЛ, и мы сможем сказать как ошибку исключить малой кровью - да там все просто. Это клиент на JavaFX - данные, представленные в GUI, скажем изменяются и сохраняются (на GlassFish через rest летит сохраняемый объект). В этом месте и показывать особо нечего:( Далее триггер в одной из таблиц при сохранении в ней данных уже смотрит условия (опять же могут быть разные триггеры и условия для разных таблиц) и сохраняет все ЛИБО откатывает транзакцию (т.е. сам откат в JPA делать не надо - я посмотрел про декларативные транзакции по вашему совету, но это не суть моего вопроса). Тут все очевидно и понятно, НО при откате естественно дать клиенту знать что мол "нееее: ты мне фигню послал так что не шали тут". Я могу эту проверку сделать на клиенте еще до попытки сохранения и ничего и не пытаться сохранить это вообще не вопрос, но тогда проверки придется делать в разных местах для разных таблиц и кроме того скажем админ напрямую сможет фигню в базу загнать (коли триггер убрать вообще). Мне подумалось что коли триггер таки с этой работой справляется уже то нефиг дублировать функции а пусть он и дальше это делает, а мы от него получаем сообщения. Причем хотелось чтобы было универсально и в одном месте все ловилось от всех возможных триггеров. Вот и все. В целом сделал так что оно фурычит, но мне просто не понравилось что я поднимаю исключение в БД и ловлю его в итоге через кучу других исключений - оттого пошел на форум за советом мож что рациональнее и проще в природе имеется.

оно работает - наверх идёт райзо до перехвата вами try - таки да! Вопрос и есть в том нормально ли это что я на БД поднимаю исключение и ловлю его через кучу других.

Petro123Ещё раз!
- триггер выдал ошибку (хотите номер, хотите строку)
- вы её перехватили?
да.

Все. Понимаю что задолбал. В итоге наверное пока остановлюсь на том что есть - оно все же работает. Когда будет БЛ с JMS горю желанием попробовать все это задружить глядишь выйдет то что мне таки понравится.

Еще раз всем спасибо!