Здравствуйте, GlebZ, Вы писали:
GZ>Странно, в Delphi есть поддержка WebService.

Я знаю что есть.

GZ> Есть другой выход. Если уж им так нравятся DataSet, то предоставлять им
GZ> XML который они могут обрабатывать с помощью ClientDataSet.
GZ> Это все-таки лучше и менее геморно, чем реализация OleDB Provider.

Технически ты абсолютно прав. Но к сожалению, для такого решения мне не хватает... ну скажем так — "административного ресурса".

Ситуация следующая:
1. Есть большое приложение сделанное в двухуровневой архитектуре.
2. В ходе развития системы стало много задач требующих сложной логики согласования/взаимодействия между сеансами пользователей. С усложнением задач рализация такого взаимодействия через тригеры в sql и временный таблицы стала громоздкой и ненадежной. Понадобился третий прикладной уровень.
3. Разработчики отказались что-либо менять (добавлять) в коде основного движка системы и ее архитектуре.

Единственная лазейка, которую мне пока удалось найти, это то, что дельфи-уровень системы никак не обрабатывает sql-опеаторы, передавая их как строки. Причем хранятся они в БД.
То есть если мне удастся подключить некий "прикладной движок" на серверной стороне и расширить синтаксис sql некоторыми прикладными командами предметной области, то дельфи-часть системы этого даже не заметит. Но для этого надо прикинуться OLE DB Provider-ом, поскольку никаких других способов общения "с внешним миром" в системе сейчас не заложено.

Здравствуйте, EXO, Вы писали:

EXO>Единственная лазейка, которую мне пока удалось найти, это то, что дельфи-уровень системы никак не обрабатывает sql-опеаторы, передавая их как строки. Причем хранятся они в БД.
EXO>То есть если мне удастся подключить некий "прикладной движок" на серверной стороне и расширить синтаксис sql некоторыми прикладными командами предметной области, то дельфи-часть системы этого даже не заметит. Но для этого надо прикинуться OLE DB Provider-ом, поскольку никаких других способов общения "с внешним миром" в системе сейчас не заложено.
Еще один обходной маневр: может быть, удастся отползти заменой ихнего TConnection на твой TConnection? К чему я клоню: написать свою реализацию TConnection на порядок проще, нежели OLE DB провайдер. Твой вариант смахивает на "давайте напишем драйвер файловой системы, потому что наши программисты ничего кроме DBF знать не хотят". Вариант, но его стоимость сравнима со стоимостью написания всей системы с нуля.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, EXO, Вы писали:

S>Еще один обходной маневр: может быть, удастся отползти заменой ихнего TConnection на твой TConnection? К чему я клоню: написать свою реализацию TConnection на порядок проще, нежели OLE DB провайдер. Твой вариант смахивает на "давайте напишем драйвер файловой системы, потому что наши программисты ничего кроме DBF знать не хотят". Вариант, но его стоимость сравнима со стоимостью написания всей системы с нуля.


"Ну ты меня убиваешь..."

Жаль, что все так сложно...
Для твоего варианта надо, чтобы они включили в свой проект чужой код...
... вою будет... на все отделы. И скорее всего 1001 прична для отказа.

Здравствуйте, EXO, Вы писали:
EXO>Жаль, что все так сложно...
Да ничего сложного нет. Тут есть камрады с опытом разработки не то ODBC не то OLE DB провайдера. Как я понял, примерная стоимость — 15 человекомесяцев. Назови это своему руководству, и дельфисты просто бегом побегут переписывать свой код на вебсервисы.