SQL in UDF

← →
Ш-К (2002-05-22 09:04) [0]

Можно ли засунуть запрос in UDF.
Т.е. например, триггер одной таблицы вызывает UDF, а UDF, в свою очередь, в другой таблице инвертирует данные.
И что, для этого в dll нужно засовывать IBX компоненты?

← →
Digitman © (2002-05-22 09:17) [1]

нет, такой возможности в IB6 не существует
и ничего никуда "засовывать" не нужно ...
вообще не очень понятно, зачем такие сложности ...может, пояснишь ?

← →
Ш-К (2002-05-22 09:47) [2]

Имеется база. Один клиент получает показания с приборов и шлёт в БД. Приборы разные, класифицируются по типам. Для каждого типа таблица. Каждая запись прибор. На каждую такую таблицу повешены триггеры, пост_евентсы и "обслуживающие" процедуры и таблицы. Да, ещё всё натянуто на пост_евентсы; для оперативного мниторинга на других клиентах. Эти таблицы отражают текущее состояние системы. Все события журнализируются. Всё работает нормально.

С недавнего времени возникла необходимость у пользователей своеручно создавать в БД новые типы устройств, а равно, и таблицы, и триггеры, и хранимые процедуры. Причём всё это должно делаться через пользовательский интерфейс кликами мышки.

Вот и пытаюсь примерить: можно ли расширить существующую систему до новой, как можно меньше перестраивая её?

И как это делать? Спасибо.

← →
Digitman © (2002-05-22 10:10) [3]

Стоп ! Какое отношение ко всему этому имеют UDF в данном случае ? Какая нестанд.функц-ть была реализована в существующих UDF до сего момента ?

← →
kaif © (2002-05-22 10:22) [4]

Согласен с Digitman © (22.05.02 10:10).
Лучше не "как можно меньне перестраивать систему", а как можно меньше перестраивать ее принципы. Мне кажется, стоит просто расширить ее новыми таблицами и процедурами, сохраняя имеющийся стиль. А сделать это можно и кликами мыши. Ведь IB позволяет использовать CREATE TABLE, CREATE PROCEDURE, CREATE TRIGGER и т. п.
Тем более стоит так поступить, если система хорошо работает.
Если нужно при этом изменить тексты каких то процедур, то это тоже можно сделать с помощью ALTER PROCEDURE. Кстати, эта команда очень хорошо работает (можно даже не отключать юзеров в момент ее применения).

← →
Ш-К (2002-05-22 11:10) [5]

2 Digitman © (22.05.02 10:10) kaif © (22.05.02 10:22)

Нестандарной функциональности UDF до сего момента не было. Её и хочу ввести. Потомучто система вынужденна расширится, имхо, ещё на одно внешнее приложение. Будет это отдельный клиент или сервер приложений не столь важно.

И если его всеравно выполнять в отдельном коннекте, то почемубы не засунуть его логику в UDF (UDF"s)? Например, данные от БД он получает через UDF, а отправляет все запросы чарез TQuery.
Почему так нельзя?

Сделать БД аморфной и к тому же работаспособной через одни креаты и алерты... я просто увязну навечно. Поэтому и нужно что-то внешнее.

А ломать базу не хочу.

← →
Johnny Smith © (2002-05-22 11:38) [6]

А организовать в UDF-шке самостоятельный коннект к базе разве нельзя?
Понимаю, что это не настолько элегантно как в Оракле (я писал в свое время внешнюю процедурку, которая делала Select"ы к базе) - там связь с базой для выполнения SQL-запросов осуществляется через т.н. контекст (то есть не открывается дополнительный коннект).

← →
Ш-К (2002-05-22 12:00) [7]

> А организовать в UDF-шке самостоятельный коннект к базе
> разве нельзя?
> Понимаю, что это не настолько элегантно как в Оракле (я
> писал в свое время внешнюю процедурку, которая делала Select"ы
> к базе) - там связь с базой для выполнения SQL-запросов
> осуществляется через т.н. контекст (то есть не открывается
> дополнительный коннект).

Вот это и пытаюсь выяснить.
Где об этом можно глянуть по подробнее?

← →
Johnny Smith © (2002-05-22 12:21) [8]

2Ш-К (22.05.02 12:00)
Где об этом можно глянуть по подробнее?
Ну, если только на www.ibase.ru

← →
Digitman © (2002-05-22 12:46) [9]

>Ш-К

Затея твоя, конечно, непростая и прелюбопытная. Только все равно непонятно, зачем ? Зачем, спрашивается, обращаться к объектам IB-базы из какой-то там UDF, если это с успехом и без всяких "фокусов" делается в SP/триггерах ? Ведь задачи, возлагаемые на UDF в общем и целом совершенно иные - реализовать нечто нестандартное, невозможное встроенными средствами механизма триггеров и хранимых процедур ! Ну, к примеру, быстро и эффективно вычислить конт.сумму чего-то там ... или, скажем, получить hash-код некоей строки ... ведь упаришься эти алгоритмы реализовывать довольно скудными возможностями интерактивного SQL, за рамки которого в SP/View/триггерах не выпрыгнешь ! А в UDF это "сотворить" - пожалуйста ! Элементарно ! Неограниченный простор для фантазии ! Быстро, наглядно и эффективно !

Ну, уж коль тебя таки "приспичило" использовать в UDF объекты IB по всем правилам, то - в чем проблема ? В чем принципиальная разница в реализации UDF и обычного приложения, реализующего доступ к IB тем или иным способом ? Да ни в чем ! Те же компоненты (если ты ими пользуешься), та же схема коннекта к базе, тот же механизм вставки/удаления/модификации записей, что предоставляет TDataSet... Единственная тонкость в том, что тело такой (как, впрочем, и любой другой) UDF не должна завершаться с исключением, ибо вызывающая UDF-функцию процедура/триггер/фильтр не сможет определить класс возникшего в UDF исключения и принять адекватные ему меры ... не говоря уже об утечках ресурсов IB-процесса, вызвавшего UDF, которая завершилась (по исключению или нормально), не позаботившись о корректном освобождении занятых ей ресурсов.

Я вижу целый ряд проблем:
1.UDF должна быть thread safe, так как одновременно работает много пользователей.
2.Неясно, при Connect из такой DLL, как password формировать.
3.Неясно, что будет происходить с транзакцией, из под которой стартовала новая транзакция, теперь уже изнутри UDF. Что, например, означает откат старшей транзакции в таких условиях?
4.Уже справедливо замечено о исключительных ситуациях, которые тоже представят собой значительный гимор, особенно в плане освобождения ресурсов в thread safe.

В общем, я боюсь, проще заново всю базу переписать.

Мда... заморочек в такой схеме, конечно, немало ... тем не менее реализовать все же можно ... но - опять же - через ж....)

Можно, к примеру, воспользоваться возможностями AppServer"а в 3-хзвенной архитектуре. Кому как не AppServer"ру знать параметры тек.коннекта и хэндлы объектов, открытых gds-клиентом в тек.сессии тек.клиента ? А связать (заставить взаимодействовать) тем или иным образом экз-р AppServer"а и UDF (для однозначной идентификации связки) вполне реально. Т.е. UDF, получив управление, передает некие параметры (определяющие, что и как нужно модифицировать в IB-бази и от имени какого клиента/сессии) диспетчеру AppServer"а, который уже, собственно, и исполняет требуемое в нужной транзакции нужного клиента, которые известны и подконтрольны ему от и до.
Да, это и дико и смешно, но - тем не менее - не исключает возможности практ.реализации ... хоть и через ж...

Я понял.
Человек хочет не функцию, а процедуру.
Низя.

← →
Ш-К (2002-05-23 00:06) [13]

2 Fay © (22.05.02 19:44)

> Человек хочет не функцию, а процедуру.

И не просто процедуру.

2 Digitman

> Зачем, спрашивается, обращаться к объектам IB-базы из какой-то
> там UDF, если это с успехом и без всяких "фокусов" делается
> в SP/триггерах ?

Абсолютно согласен. Только в моём конкректном случае БД с изменяемой структурой, пользоваться одними возможностями IB накладно по причине маштабности приложения. Не спорю: всё, что мне надо, можно решить в рамках SP/View/триггерах. Проблема в том, что я не безграничен во времени.

Вот и приходится искать обходные маневры. Такие, как расширение возможностей UDF"s.

Понятно, что использование IB компонентов в UDF приведёт к неизбежным проблемам. Тогда уж лучше и не загонять их в библиотеку.

Как такой вариант?
Строится трёхзвенка. Даже и не она совсем. AppServer лежит не прослойкой, а где-нибудь позади базы. И служит расширением возможностей БД под мою конкректную задачу. (Реализовать возможности через AppServer мне легче раз в 10, чем делать то же средствами IB).
Когда пользователь создаёт новую таблицу, в неё автоматически добавляются триггеры. В триггерах находятся те самые UDF, о которых я говорю с самого начала. Для каждой таблицы они одни и теже (допустим их 6, по типам триггеров).
Так вот, UDF ничего не делает, только передаёт данные на AppServer через WM_CopyData (DDE, Sockets...) На AppServer"е данные успешно принимаются и обрабатываются в отдельных потоках.
Очень похоже на post_event/EventAlerter, с той лишь разницей, что сразу поступают данные, а не зарегистрированные посты.

Если рассматривать каждую таблицу как тип приборов, а запись как сам прибор, такой подход снимает много проблем. Я могу добавлять прибор, удалять, следить за изменениями. Похоже на ООБД.

Наверника, кто-то делал нечто подобное.
Будут ли тут проблемы?
Может существуют другие, готовые решения/компоненты?

kaif © (22.05.02 14:58)

> В общем, я боюсь, проще заново всю базу переписать.

А как ты это представляешь? Можешь по конкретнее?
Спасибо.

SQL in UDF Найти похожие ветки