Здравствуйте.
В ходе работы на проектом возникла следующая задача. В процессе выполнения хранимой процедуры в БД Firebird 2.5 x64 необходимо следующее.
1. Выполнить хранимую процедуру в БД MSSQL Server 2008 и возвращаемый ей набор данных положить во временную таблицу Firebird либо в MemoryDataset (этот вариант предпочтительнее с точки зрения быстродействия). Эти данные должны быть доступны только внутри этого вызова хранимой процедуры Firebird и после завершения занимаемая им память должна быть освобождена.
2. В случае MemoryDataset произвести один или несколько проходов по этому датасету для формирования итогового набора данных и его возврата (suspend) в клиентское приложение.

Вариант с подключением к MSSQL через компоненты FireDAC или ADO отпадает так как стоит сверх-задача сделать получение данных из MSSQL прозрачным с точки зрения клиентского приложения, которое "заточено" на работу с Firebird.

Прошу поделиться мнениями, идеями и ссылками. Ответ "не возможно" не принимается. Позади Сибирь. http://www.sql.ru/forum/images/biggrin.gif

Товарищ старший сержант,
Разрешите доложить. я знаю только UDF.
Что есть UDR и где по него грамотно написано?

WildSery,
все необходимые данные и так уже находятся в БД MSSQL и меняются там в реальном времени.
собственно по этому и весь этот сыр бор.
в таком ключе не понимаю что вы подразумеваете под костылем? утилите по заливке изменений из MSSQL в Firebird?

Василий №2Навскидку

1. 3 UDF:
- DBConnectAndExecQuery(Addr): QueryPtr
- QueryGetRowAndNext(QueryPtr): Field1, ..., FieldN
- CloseQueryAndDB(QueryPtr)

Из QueryGetRowAndNext запихиваем во временную таблицу, там крутим, выдаем клиенту, очищаем.
Минусы - фиксированный набор полей в UDF, что означает пересборку при изменении. Либо придется мутить с упаковкой-распаковкой, что на SQL не очень приятная задача.

2. Приложение-посредник и 1 UDF.
UDF при вызове дергает приложение (через пайпы, сокеты и т.п.), приложение перекачивает данные, ХП их обрабатывает.
Но:
- ХП должна как-то подождать, пока приложение перекачает данные (можно обеспечить внутри UDF)
- ХП должна увидеть данные внутри уже начатой транзакции (достигается параметрами транзакции)
- Клиент должен быть строго один; либо записывать данные в таблицу вместе с ИД клиента.

3. Элементарно репликация в FB.
Минусы - возможно будет много лишних операций. Зато наиболее надежно.

4. (возможно, если UDR подерживает передачу текущего соединения) Переход на ФБ 3 и закачка данных из UDR непосредственно во временную таблицу (вариант №1, но более краткий и устойчивый).

Спасибо
Вот первый вариант мне более всего нравится исходя из того что данные в БД MSSQL меняются в реальном времени.
Есть несколько вопросов.
1. Что есть параметры Addr и QueryPtr?
2. При написании UDF в Delphi 2010 имеем 32-битную DLL. Заведется ли на Firebird 2.5 x64?
3. А если так QueryGetIntValue(QueryPtr, 'FieldName'), QueryGetStringValue(QueryPtr, 'FieldName') и т. д? Естественно с предварительно проверкой на тип данных в поле. Ведь типов данных ограниченное количество в отличие от количества полей.

Василий №2po-stroykaЕсть несколько вопросов.
1. Что есть параметры Addr и QueryPtr?
2. При написании UDF в Delphi 2010 имеем 32-битную DLL. Заведется ли на Firebird 2.5 x64?
3. А если так QueryGetIntValue(QueryPtr, 'FieldName'), QueryGetStringValue(QueryPtr, 'FieldName') и т. д? Естественно с предварительно проверкой на тип данных в поле. Ведь типов данных ограниченное количество в отличие от количества полей.
1. Addr - строка подключения к MSSQL, можно также встроить в DLL либо читать DLL-ю из конфига, не принципиально. QueryPtr - указатель на созданный внутри DLL объект запроса. Можно и глобальной переменной внутри DLL сделать, но это менее устойчиво (разве что объявить как threadvar).
2. Конечно нет, разрядность должна совпадать. Либо брать Дельфи поновее, либо Lazarus, либо другие языки.
3. Как вариант, хотя тогда количество UDF будет больше, плюс весь процесс замедлится (правда, не так уж сильно). Зато более универсально, да.

Если MSSQL умеет взаимодействовать с FB, то еще вариант - UDF дергает MSSQL, тот заливает данные в FB с ИД текущего FB-подключения, ХП в FB дальше с ними работает. Транзакция клиента в FB при этом д.б. read_committed.

Огромное спасибо.
Сам думал про что то подобное. Благодаря Вам многое встало на нужные полочки.
Готовой DLL-кой поделюсь.
>>> 2. Конечно нет, разрядность должна совпадать. Либо брать Дельфи поновее, либо Lazarus, либо другие языки.
Дельфи поновее надо будет опять покупать. Возможно придется откатиться на Firebird x32. Или откатка не поможет?

Filippov Dmitrypo-stroyka,
а там без процедуры никак?
Если бы переписать ее во VIEW, то там бы Linked Sever -а бы хватило.
С минимальным уровнем шаманств.

Насколько я понимаю Linked Sever - это для подключения из MSSQL к Firebird-у. А мне нужно наоборот и чтобы сама хранимая процедура Firebird инициировала подключение и получала данные из MSSQL.

Симонов Денисpo-stroyka,

по уму надо переходить на FB 3 и писать UDR процедуру.
А передача указателей через UDF это полный изврат

1. Backup на v2.5 и restore v3 БД нужно?
2. Для UDR имеет значение разрядность x86/x64?
3. Можно ссылочку чтобы было грамотно написано про написание UDR?

Мимопроходящийпо теме:
постановка задачи - говно.
советы как её решить через жопу, тоже.

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



Благодарю Вас за мнение. Будете еще раз проходить мимо, проходите.

Симонов Денисpo-stroyka,

1. Backup на v2.5 и restore v3 БД нужно? - да (возможно придётся подкручивать)
2. Для UDR имеет значение разрядность x86/x64? - да, если только udr не написана на Java
3. Можно ссылочку чтобы было грамотно написано про написание UDR?
нет пока никаких ссылок. Есть пример простейшей UDR на Delphi https://github.com/asfernandes/fbstuff/tree/master/src

Благодарю Вас за ценные советы. Будете проходить мимо, заходите на огонек :-)