Приветствую!
1. Создал процедуру на удаленном сервере:



2. На основном серваке сделал процедуру для вызова удаленной:

Которая просто вызывает удаленную процедуру.

3. Пытаюсь на основной базе создать триггер на удаление и в нем вызвать удаленную процедуру, через основную:


Идет ругачка :
Error: ERROR [25000] [IBM][DB2/NT64] SQL30090N Operation invalid for application execution environment. Reason code = "22".

Я слишком многого хочу от DB2? В триггере невозможно вызывать удаленные процедуры ?

Mark Barinsteinmedoed В триггере невозможно вызывать удаленные процедуры ?
Добрый день.

Согласно RC=22, если процедура объявлена как MODIFIES SQL DATA, то нельзя.

db2 "? SQL30090"
...
22 A federated insert, update, or delete operation, or a call to
federated procedure with an SQL data access indication of
MODIFIES SQL DATA is invalid in a function, a
data-change-table-reference, a dynamic compound statement, a
trigger...
Это весьма грустно Марк!

Марк, а можно я все же задам накипевший вопрос? А почему создатели ядра такое сделали, в функциях в динамике работать с NickName нельзя. В триггере дергать процедуру или использовать NickName для модификации данных на удаленно сервере тоже?
Для чего??? Я разработчик и мне решать, что можно или нельзя делать на удаленном сервере - а то что сейчас каждый раз мне дают по рукам разработчики ядра - тошнит уже и руки опускаются!
Они (разработчики ядра СУБД DB2) наверное гордятся этим и не собираются исправлять, да?

Mark Barinsteinmedoed,

Эти ... федерасты сидят далеко от разработчиков ядра, они свою работу как сделали, так сделали...
Сидят там у себя на другом континенте, только жизни загубленные себе звёздочками на фюзеляже подрисовывают. Вот ещё одна, похоже, вырисовывается :)
Но вы, как заказчик, можете заставить их работать с помощью т.н. RIMS (aka DCR) - запросов на расширение функциональности. Если вы не будете этого делать, то сама эта нужная, может быть, только вам функциональность делаться неизвестно для кого не будет. Эти разработчики просто не узнают, что это кому-то надо...
Меня как клиента не должно волновать - где сидит команда! Тем более в эру современных технологий скайпа и видеотрансляций!
Я посылал свою хотелку в декабре прошлого года- даже ответа не было!
Компания вроде крупная, есть и прогеры и тетстеры и манагеры - а такой отстой в архитектуре творится!
disable/enable триггер нету ну это писец по-моему!

anton.kФедеративной инфраструктуре в DB2 for LUW много лет. Я не сильно ошибусь если скажу, что добавлена она была лет 15 тому назад. В те времена драйвера, используемые DB2 для связи с удаленными базами данных, не обладали механизмами необходимыми для корректной реализации некоторых фундаментальных принципов СУБД (именно в рамках федеративной инфраструктуры). Например, DB2 не могла гарантировать, что в случае dynamic compound statements (сейчас они называются compound inlined statements) все remote statements, на которые разбивается compound statement, завершаться в рамках одной транзакции. То есть это не было ограничение DB2 или федеративной инфраструктуру, просто инструментарий, на который опиралась DB2, не поддерживал требуемого функционала.

Изменилась ли ситуация сейчас? Не берусь утверждать наверняка, но с осторожностью предположу, что да. Тогда почему не добавили до сих пор поддержку INSERT/UPDATE/DELETE запросов и федеративных функций, определенных как MODIFIES SQL DATA, в триггеры, функции и compound statement'ы? Марк вам совершенно точно уже ответил на этот вопрос - потому что никто об этом не просил (либо просили недостаточно настойчиво :) Так что если оно вам очень сильно надо - начинайте трясти тех. поддержку. Насколько я помню, не так давно изменился процесс подачи и обработки запросов на расширение функциональности, по идее должно было стать проще.
За 15 лет должно уж что то поменяться!!! Я писал им раннее об этой проблеме - ноль эмоций! Ну я доложил об ограничениях СУБД начальству, как следствие (в том числе) мы переходим в 2015 на ту СУБД, в которой таких дебильных проблем нет (MSSQL)!
И более того, если меня когда то спросят, как консультанта про выбор базы - никогда не посоветую DB2!!!
Я в MSSQL тоже натыкался на проблемы, но это было раза 2-ва за 5-ть лет, здесь же за 2-ва года на 5-7 на крупных камня наступил!
Вообщем DB2 буду рекомендовать тока врагам )

mustaccioanton.kНасколько я помню, не так давно изменился процесс подачи и обработки запросов на расширение функциональности, по идее должно было стать проще.

Чтобы не быть голословным -- новая книга жалоб и предложений здесь: https://www.ibm.com/developerworks/rfe/
Уже неинтересно, пусть получат пилюлей от какого нить крупного клиента, желательно перед рождеством! Чтобы то что за 15 лет не довели до ума - аврально исправляли!!!

n&nmedoed...пусть получат пилюлей от какого нить крупного клиента, ...
пмсм, крупным (действительно крупным) клиентам все это глубоко безразлично.
Они берут готовые решения от крупных вендоров, в точ числе и от самой IBM.
Видел только несколько таких решений и судя по ним основной тренд эти 15 лет -
переносить любые распределенные операции на уровень сервисных приложений
(Хоть тот же стек WebSphere).
Может поэтому и нет нет смысла развивать такой функционал в СУБД.
А я видел трейдинговые системы как раз с логикой на СУБД (это было на MSSQl), думаю на DB2 такое бы не взлетело!

anton.kmedoedУже неинтересно, пусть получат пилюлей от какого нить крупного клиента, желательно перед рождеством! Чтобы то что за 15 лет не довели до ума - аврально исправляли!!!
Ну то есть тот факт, что за все это время востребованность данной конкретной функции не достигла критической массы, достаточной для того, чтобы разработчики DB2 добавили ее поддержку (при том, что вам достаточно внятно объяснили, почему это не было сделано изначально, а так же почему это не было сделано в последующее время ), наводит вас на один единственный вывод, что архитектура DB2 - отстой? Я правильно вас понял?
Нет конечно. Ноя не понимаю, почему если на одном инстансе развернуто несолько баз DB2 возникают вообще какие то проблемы при коммуникации между ними. В MSSQL я просто могу в запросе написать так: select * from base1.dbo.table1 as t1, base2.dbo.table1 as t2 where t1.id = t2.id без всяких MQT и NICKNAME (base1 и base2 разные базы), ну не умеет так db2, ну пусть сделает полную функциональность между федеративными серверами! Но нету ее ни шиша!
А насчет востребованности - если в db2 disable/enable для триггеров не возможен а только drop/create, то явно показывает отношении компании на клиентов, я ее с помощью картинки продемонстрирую (пользователи на переднем плане, отношение db2 к клиентам на заднем):

A.Panskikhmedoed,

db2 ориентирована на крупных кастомеров, где срок и стоимость разработки систем несравнимы со сроками и стоимостью поддержки.
Из этого построена вся идеология системы и продуктовой линейки IBM.

Что такое "дернуть хранимую из триггера". Это значит, что часть кода из транзакция уйдет безконтрольно. Что произодет при роллбэке? Что произойдет при зависании внешней хранимой процедуры? Во сколько денег выльется поддержка, сколько будет стоить развернуть тестовый/девелоперский стенд, провести интеграционное тестирование? Извращения программиста потом выливаются в невозможность нормально поддерживать систему, безумные затраты на модификацию и тестирование.

Поэтому ни одному кастомеру IBM этого не надо.

Мой совет - либо выберете более удобное для ваших задач решение, либо примите правила разработки.

Идеология DB2 в двух словах - кесарю кесарево. В БД лежат данные, на сервере приложений - код, интеграционная компонента - шина, транспортный уровень - MQ, процессами рулит process manager, для распределенных транзакций используем TM, и т.д. Все компоненты информационной инфраструктуры представлены IBM и даже в нескольких вариантах. При этом ничто не мешает заменить каждый компонент на продукт от другого вендора и/или на иной платформе.

Если данный подход не устраивает, выбираете любое другое решение, которых на рынке с идеологией
"Лосьен Огуречный! Выпивка и закуска в одном флаконе!" полно (и задать себе вопрос - а почему полно?).
AP
Вы на себя взяли авторитетное мнение за всех кастомеров, ну ну ? Ну я давно понял, что если логика на стороне СУБД (такие системы все же есть, как вариант для быстродействия) то DB2 для таких решений -УГ! Про удобство для клиентов я привел конкретный пример с alter/disable trigger этого нет в DB2, но есть в MSSQL, SYBASE,ORACLE. Вывод прост - Db2 неудобна как минимум. Хотя по вашей логике триггеры вообще не нужны, все контролим на сервере приложений Наша компания уже выбрала решение и то что она отказывается от DB2 - это верное решение (как мне видится), потому как сама СУБД имеет слишком много ограничений да и в администрировании тяжела, в отличие от MSSQL, где многое можно сделать нативно!

A.Panskikh,
Много буков выше и анекдотец заплесневелый!
Я лишь о том что DB2, заявляемая как полноценная СУБД таковой не является по сути, даже потому что нельзя disable/enable триггер не поддерживается и даже потому что НЕПОЛНОЦЕННО организованы федеративные связи, могу ещё кучу багов привести!
Далее можете все что угодно писать и тролить, но против фактов не попрешь!!!
Ау фидерзейн!

Victor MetelitsaВспоминается анекдот про Буратино и винтик. Тот, где Буратино обнаружил винтик у себя в пупке и ради любопытства его раскрутил. Но то про деревянного ребёнка. А эта эпопея... В одной базе запросы работают полноценно, но надо обязательно сделать из неё две. Запрос с реплицированными данными будет работать быстрее (поскольку в одной базе), но надо обязательно использовать никнейм. Так, по дороге, пришли к Java-функции - самому тормознутому решению из возможных. И наконец упёрлись в триггера, которые не позволяют. Зачем всё это затевалось, совершенно непонятно.
Радует, что вам еще что то вспоминается
Несколько баз было сделано из за блокировок и тормозов на одной. Разные клиенты на разных базах и одна справочнная база общая, не самое лучшее решение, но и не самое плохое (этому решению лет 7-мь и придумалось до меня). MQT при обновлении нехило дает блокировки, поэтому постарались внедрить NICKNAME где это возможно (пока что не пожалели). Java функции придумал ваш мозг, в который нежданно пришли фантазии . Триггер рассматривался как вариант синхронизации между справочной базой и основными при удалении справочника, да через NickName и в таком подходе я не вижу ничего криминального!!!
В MSSQL и Sybase на базе BASE1:
это бы работало без проблем!!!
А DB2 встает раком!

db2manVictor MetelitsaВспоминается анекдот про Буратино и винтик. Тот, где Буратино обнаружил винтик у себя в пупке и ради любопытства его раскрутил.
....и теперь у "буратины" этого "бисер" не усваивается (постоянно отрыгивается фекалиями) , так что, парни, завязывайте с "метанием", бо не в свинью коня корм

Victor Metelitsa Зачем всё это затевалось, совершенно непонятно.
Так бывает, когда "разруха в головах". Здесь можно только обнять и плакать "панять и пгастить"
А вы посмотрите % распространенности у нас на рынке СУБД DB2 (по сравнению с Oracle и MSSQL) где нет лоббирования - неудобно, поэтому мало кто выбирает!
Это неспроста!

anton.kmedoedпропущено...

Нет конечно. Ноя не понимаю, почему если на одном инстансе развернуто несолько баз DB2 возникают вообще какие то проблемы при коммуникации между ними.

Если "нет конечно", то тогда, наверно, не стоило делать столь категоричное заявление, потому что подобные эскапады выставляют вас в весьма неприглядном свете. Далее, если вы чего-то не понимаете, то это, опять же, не дает вам право отзыаться нелестно о предмете обсуждения, в котором вы, по вашему же собственному утверждению, не разбираетесь - это отбивает всякое желание вести с вами диалог. Слушайте, вникайте, и делайте правильные выводы. Здесь люди тратят на объяснение ваших вопросов свое личное время, пытаются вам помочь и делятся информацией, которую, возможно, вы больше нигде не найдет - уважайте их за это, и ведите себя подобающим образом (это к вопросу о картинках, которым место в вашем Фйесбуке, а не на техническом форуме).

medoedЯ лишь о том что DB2, заявляемая как полноценная СУБД таковой не является по сути, даже потому что нельзя disable/enable триггер не поддерживается и даже потому что НЕПОЛНОЦЕННО организованы федеративные связи, могу ещё кучу багов привести!
Далее можете все что угодно писать и тролить, но против фактов не попрешь!!!
Что значит неполноценная СУБД? Как вы это оцениваете? Мне не хватает какой-то функции, значит система неполноценная? А как вам такой факт: DB2 - коммерчески успешный продукт с многомиллиардным оборотом и внушительной базой клиентов по всему миру. Почему все они пользуются "неполноценной" СУБД и еще и платаят за это деньги? В чем подвох?
В чем вопрос? Я считаю, что если нет полного функционала (а не отдельной функции) по федеративным связям (на удаление или изменение данных на удаленном источнике) - то да? я считаю такую СУБД не полноценной (тем более что здесь один и тот же источник данных база DB2). Мне есть с чем сравнивать, я поработал с базами Sybase, MSSQL и Oracle. На этом закончу, в этой теме я Марка просил ответить и он ответил по существу, за что ему спасибо!
Вы же свое уникальное и дорогущее время не тратьте на меня, тратьте только на продукты IBM, главное чтобы они вас вставляли!!!