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

BG>>Судя по оценкам мнения разделились.
M>Да не разделились, тот минус был скорее политический, иначе Мика рискнул бы изложить свои соображения...

Wild shot — wild miss on my part

BG>>В случае распределенных трансакций — нужна.
M>Распределенные транзакции — это отдельная пестня, ну допустим нам приспичило делать их с помощю Web-сервисов...

BG>>Например тот же самый веб шоп. У Вас трех-звенка:
BG>>1. Front-End
BG>>2. Middleware
BG>>3. your Database

BG>>4. Credit Card Webservice.

BG>>Удобнее всего гнать транзакцию с номера 2. Т.к. 4. часто бывает сильно удаленным, трансакция получается распределенной.
M>Да не факт, удобнее разделить это на несколько транзакций.
M>1. заказ переводится в сосояние "ожидание оплаты" (2-3)
M>2. запрос на авторизацию кредитки через Web-сервис (2-4)
M>3. в случае успеха перевод заказа в состояние "ожидание отгрузки" и сообщения об этом радостном известии юзеру (3-2)
M>3а. в случае неуспеха заказ остается в состоянии "ожидание оплаты" и сообщается об этом печальном событии юзеру с просьбой повторить ввод.

M>Никакой необходимости делать все в одной большой транзакции нет, однако с точки зрения юзера все выглядит так, как буд-то транзакция одна и большая.

Абсолютно с Вами согласен. Я не фанат распределенных и декларативных трансакций — т.к. их очень тяжело контролировать. К сожалению, технология двигается именно в направлении декларативных трансакций, поэтому хошь, не хошь, а связываться с ними приходиться. Я просто выбрал этот простой пример, что бы объяснить необходимость такого рода вещей.

Не очень хочу распространятся с чем именно счас приходится работать, но в общем ситуация такая:
1. есть главная оракловская база
2. есть второстепенная оракловская база
3. есть аудит сервис сделанный хрен знает на чем (не в курсе на чем он сделан, знаю только что железка стоит 50К) — на нас смотрит вебсервис, куда мы пихаем свои данные.
4. есть еще пара машин db2 — тоже с вебсервисами. — legacy
5. есть еще и страшный зверь TIBCO — на него мы тоже глядим через вебсервисы. — legacy

Наша группа занимается front end/middle ware — т.е. кастомер чей-то там кликнул и нам надо пускать трансакцию по всем пяти Data Sources. Ситуация почти как на микрософтовском экзамене, только вот в реальной жизни. Никогда не думал, что увижу такие вещи.

Иногда приходится и длинный xml туда сюда пихать в трансакции — некрасиво, конечно, но что делать?

BG>>Вот Вам и закачка большого xml файла между участками 2/3 и 4.
M>Только 2-4 DB, таким образом, остается не затронутым и спокойно работает в привычном режиме.

Я просто предложил академический пример, который все используют для объяснения ситуации. Вдаваться в тонкости архитектуры я счас не очень хочу. Ибо можно сделать проще, да. Но не всегда. К тому же эти решения часто бывают приняты очень давно и изменить их уже нельзя.

BG>> Домыслить остальное предоставляется читателю в качестве самостоятельно упражнения.
M>Еще примеры необходимости XML траффика в транзакции есть?

Да куча. Любой обмен информации с legacy источниками счас происходит именно через xml. Очень удобно кстати сказать, потому как не надо учить архаичную архитектуру AS400 или чего-нибудь там еще. Нам просто дают xml schema и усе

Здравствуйте, Merle, Вы писали:
M>>Никакой необходимости делать все в одной большой транзакции нет, однако с точки зрения юзера все выглядит так, как буд-то транзакция одна и большая.

M>Это я все к тому, что, как правило, нет необходимости вовлекать БД в пользовательские транзакции (кроме как посредством пользовательских блокировок, которые аккурат для этого и предназначены), особенно если оные транзакции шибко длинные и распределенные.

Опять же не сильно с Вами соглашусь. Я рассматриваю БД как persistance storage — т.е. все что туда попало, никогда уже без причины оттуда не выпадет. В этом смысле очень удобно использовать БД как механизм/контроллер управления трансакциями в Enterprise условиях. Оракл, кстати сказать, под это и заточен, поэтому я и написал, что он любит длинные трансакции и за ними очень хорошо следит.

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

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

BG>>Судя по оценкам мнения разделились.
M>Да не разделились, тот минус был скорее политический, иначе Мика рискнул бы изложить свои соображения...

Мерле, а если бы я тебе поставил знак "+" что бы ты тогда ответил?

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

BG> будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
А кому нужна транзакция на скачивание xml-файла? Транзакция нужна когда идет обработка логики по полученным данным, а здесь уже можно сделать ее достаточно короткой практически всегда.

Представь себе такую ситуацию. Размер закачиваемых данных очень большой, притом что клиент использует портативный тип ПО (смартафон). Логичнее всего при закачке сразу запустить процесс обработки данных, дабы не заставлять ждать пользователей несколько часов. При этом процессе могут происходить опять же ображение к другим источникам данных. Получается, что если наше первоначальное ображщение к серверу прервется, то должны откатиться все изменения.

Такая система может пригодится, например, при анализе рисков в предприятии. По полученным данным он сможет видеть как стоится график. Он может и не дожидаться окончания построения данных, увидев нужную картину, которая построилась по не полной информации (например, посмотреть динамику изменения вероятностей в начальный период).

Так же еще в твоем высказывании был такой спорный момент, что своим высказыванием ты фактически перечернул такую технологию как MQ, или WS-Transaction, где в рамках транспортной транзакции можно выполнять физические транзакции с источниками данных.

Если ты считаешь, что оценка не заслужена, то я могу ее убрать. Но я все же считаю, что ошибать — не зазороно. Хороший специалист имет право на ошибки.

зы К сожалению у меня не так много времени в последнее время. Так что я ограничусь выражением своего мнение постановкой оценок. Надеюсь никто не против? Если уж что срочное, постараюсь отписать.

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

BG>Опять же не сильно с Вами соглашусь. Я рассматриваю БД как persistance storage — т.е. все что туда попало, никогда уже без причины оттуда не выпадет.
Да байта ради, что я — зверь какой? То что я изложил ни чуть этому не противоречит...

BG> В этом смысле очень удобно использовать БД как механизм/контроллер управления трансакциями в Enterprise условиях.
Удобно, вопрос только как именно.. Пихать в лоб длинную транзакцию в БД — не самое удачное решение...

BG> Оракл, кстати сказать, под это и заточен, поэтому я и написал, что он любит длинные трансакции и за ними очень хорошо следит.
Вот тут я, пожалуй, немного не соглашусь длинные транзакции не любит никто, другое дело, что Оракл гораздо терпимее к ним относится.

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

BG> Я просто выбрал этот простой пример, что бы объяснить необходимость такого рода вещей.
Я нигде не говорил, что такой необходимости в принципе быть не может, и очень аккуратно употреблял всяческие "почти", "практически", ect.. Но, как правило, необходимость в подобного рода решениях обусловлена не чисто техническими соображениями, а скорее политическими "стоимость разработки", "обратная совместимость", ect..

BG>Я просто предложил академический пример, который все используют для объяснения ситуации.
А я дал академическое решение..

BG>Да куча. Любой обмен информации с legacy источниками счас происходит именно через xml. Очень удобно кстати сказать, потому как не надо учить архаичную архитектуру AS400 или чего-нибудь там еще. Нам просто дают xml schema и усе
Да понятно что xml, на БД транзакции-то этот xml зачем завязывать?
Я не говорю о всевозможных legacy конструкциях, но при решении таких распределенных задач, в общем случае, "правильным" подходом было бы использование некого координатора этих самых расперделенных транзакций. БД, при этом, используется только если координатору нужно хранить какие-то промежуточные состояния, и в случае сбоя координатор выполняет компенсирующие транзакции для отката состояний. При этом и БД не нагружена, и за длинными транзакциями следит механизм специально для этого предназначенный.

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

MS>Мерле, а если бы я тебе поставил знак "+" что бы ты тогда ответил?
А тогда бы расхождения во мнениях не было..

MS> Но есть и ошибка в твоих суждения.
Да вроде нет.
Похоже ты просто не уловил суть моих рассуждений. Они сводились не к тому, что я против передачи данных в транзакции, а к тому, что эта транзакция обязательно должна быть частью БД-транзакции. Видимо я не достаточно ясно выразился.

MS>Представь себе такую ситуацию. Размер закачиваемых данных очень большой, притом что клиент использует портативный тип ПО (смартафон). Логичнее всего при закачке сразу запустить процесс обработки данных, дабы не заставлять ждать пользователей несколько часов. При этом процессе могут происходить опять же ображение к другим источникам данных. Получается, что если наше первоначальное ображщение к серверу прервется, то должны откатиться все изменения.
Хм.. Ну, пример довольно сомнительный, а если речь идет именно про БД транзакции, то и вообще невозможный. Более того, собственно необходимости в БД транзакциях я здесь не вижу.

MS>Так же еще в твоем высказывании был такой спорный момент, что своим высказыванием ты фактически перечернул такую технологию как MQ, или WS-Transaction, где в рамках транспортной транзакции можно выполнять физические транзакции с источниками данных.
Вовсе нет. В рамках транспортной транзакции, БД транзакций может быть сколько угодно, но вот если эта транспортная транзакция выполняется в рамках БД транзакции, то здесь явно какой-то косяк...

MS>Если ты считаешь, что оценка не заслужена, то я могу ее убрать.
Да байта ради, это же твое мнение..

MS> Но я все же считаю, что ошибать — не зазороно. Хороший специалист имет право на ошибки.
Спасибо за комплимент, но пока вроде ошибок нет, что делает меня еще лучше..

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

BG>>Опять же не сильно с Вами соглашусь. Я рассматриваю БД как persistance storage — т.е. все что туда попало, никогда уже без причины оттуда не выпадет.
M>Да байта ради, что я — зверь какой? То что я изложил ни чуть этому не противоречит...

BG>> В этом смысле очень удобно использовать БД как механизм/контроллер управления трансакциями в Enterprise условиях.
M>Удобно, вопрос только как именно.. Пихать в лоб длинную транзакцию в БД — не самое удачное решение...

Вопрос по большей части философский. Возьмем такой сценарий:
К вам на файловую систему свалился бааальшой такой xml200504272152.OUT
Когда Вы начали с ним работать, Вам надо его переименовать в .INPROCESS, что бы другая нода (а их пара сотен) не взялась за этот же файл и не стала выполнять ту же саму работу, которую выполняет наша нода.
Вам его надо распихать по 5 различным базам данных.
Да так, что бы если одна из этих пяти баз данных (скажем номер 4) Вас обломала, Вам бы стоило вернуть все предыдущие в то состояние в котором они были, до начала Вашей операции.
И в зависимости от успеха предыдущей операции переименовать в xml*.IMPORTED или xml*.NOTVALID или ваапще удалить нах.

Скажем у вас есть w2k server, .net и оракл. Файловая система на текущий момент трансакционность не поддерживает, поэтому участниками/координаторами трансакций будут oracle, и ms dtc. Каждый из которых понимает трансакцию по своему.

Грубо говоря речь идет о семантическом расширении понятия транзакции Т.е. вместо одной базы данных, транзакция может включать в себя гораздо большее количество элементов — файловые системы (в недалеком будущем), веб сервисы, етц, етц. В этом смысле Enterprise Services и декларативное описание трансакций очень полезно, т.к. Вам не нужно вдаваться в подробности описания транзакций того или иного участника, а просто сказать, что все что внутри данного метода/класса должно выступать в качестве т. Согласить — это круто Я вот тоже так считаю, и все вот жду когда же это наконец заработает

BG>> Оракл, кстати сказать, под это и заточен, поэтому я и написал, что он любит длинные трансакции и за ними очень хорошо следит.
M>Вот тут я, пожалуй, немного не соглашусь длинные транзакции не любит никто, другое дело, что Оракл гораздо терпимее к ним относится.

Опять же вопрос понятийный. Но Вы и сами наверняка замечали, если Вы сидите и бьетесь головой об стену, пытаясь решить какую нибудь проблему, стоит Вам только подойти к кому-нибудь объяснить свою проблему словами, как решение придет само, еще до того, как Вам ответят. Решение приходит как только Вы заставили себя формализовать проблему. Так же и в этой дискуссии: можно долго сидеть и читать книжки по трансакциям и Enterprise Services, долбаться с академическими примерами (тот же самый веб шоп) и думать: на фига наращивать такой геморрой для простого веб шопа — можно ведь сделать и проще. Можно сделать и проще, да. Но на академических примерах можно научится решать только академические задачи — в реальной жизни все гораздо сложнее. Впрочем, что я Вам об этом рассказываю, Вы и сами об этом знаете

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

M>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Мерле, а если бы я тебе поставил знак "+" что бы ты тогда ответил?
M>А тогда бы расхождения во мнениях не было..

Не знаю как у других, но я за неправильные ответ тебе + ставить не буду

MS>> Но есть и ошибка в твоих суждения.
M>Да вроде нет.
M>Похоже ты просто не уловил суть моих рассуждений. Они сводились не к тому, что я против передачи данных в транзакции,

Если бы ты такое опротестовал, то я думаю не только я бы тебе поставил минус

M>а к тому, что эта транзакция обязательно должна быть частью БД-транзакции. Видимо я не достаточно ясно выразился.

Доводы

MS>>Представь себе такую ситуацию. Размер закачиваемых данных очень большой, притом что клиент использует портативный тип ПО (смартафон). Логичнее всего при закачке сразу запустить процесс обработки данных, дабы не заставлять ждать пользователей несколько часов. При этом процессе могут происходить опять же ображение к другим источникам данных. Получается, что если наше первоначальное ображщение к серверу прервется, то должны откатиться все изменения.
M>Хм.. Ну, пример довольно сомнительный, а если речь идет именно про БД транзакции, то и вообще невозможный.

Ну почему же? Очень даже возможный. Мы открываем транзакцию и начинаем считывать посегментно файл. Если данные прерываются, в базу заносим запрос Rollback. Если все нормально, то Commit.

M>Более того, собственно необходимости в БД транзакциях я здесь не вижу.

Обработка данных — это процесс с их изменением. Если здесь не применять транзакцию, то при прерывании загрузки файла может случиться ситуация с несогласованностью данных.

M>Вовсе нет. В рамках транспортной транзакции, БД транзакций может быть сколько угодно, но вот если эта транспортная транзакция выполняется в рамках БД транзакции, то здесь явно какой-то косяк...

Ну хоть с первым разобрались Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция. В ее рамках выполняется транспортная. В данном случае — это пересылка данных по протоколу TCP (напомнить, чем отличается он от UDP). Теперь повысим уровень асбтракции транспортной транзакции до MSMQ. Вуаля — твое утверждение не верно.

MS>>Если ты считаешь, что оценка не заслужена, то я могу ее убрать.
M>Да байта ради, это же твое мнение..

Ну вот видишь. А то политика, милитика

MS>> Но я все же считаю, что ошибать — не зазороно. Хороший специалист имет право на ошибки.
M>Спасибо за комплимент, но пока вроде ошибок нет, что делает меня еще лучше..

Правильно. Если себя не похвалишь, кто еще это сделает.

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

MS>Не знаю как у других, но я за неправильные ответ тебе + ставить не буду
Ну, за правильный мог бы, тем более, что сам явно что-то не то рассказываешь..

MS>Ну почему же? Очень даже возможный.
Работать с еще не зафиксированными данными ни одна вменяемая БД не даст.

MS>Мы открываем транзакцию и начинаем считывать посегментно файл. Если данные прерываются, в базу заносим запрос Rollback. Если все нормально, то Commit.
Зачем на этом этапе открывать БД транзакцию?

MS>Обработка данных — это процесс с их изменением. Если здесь не применять транзакцию, то при прерывании загрузки файла может случиться ситуация с несогласованностью данных.
Каким образом? загрузка — это только загрузка, если очень хочется во время этой загрузки как-то эти данные отображать — бога ради, но к БД это не имеет никакого отношения и в случае сбоя ни к каким проблемам не приведет.

MS> Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция.
Есть.

MS> В ее рамках выполняется транспортная.
Зачем? Откуда здесь взялась транспортная транзакция?

MS> В данном случае — это пересылка данных по протоколу TCP (напомнить, чем отличается он от UDP).
Пересылка данных происходит вне контекста транзакции.

MS> Теперь повысим уровень асбтракции транспортной транзакции до MSMQ. Вуаля — твое утверждение не верно.
Я нигде не утверждал, что так делать нельзя, я утверждал, что так делать не правильно. А то что способов прострелить себе ногу есть придостаточно — никто не спорит.

M>>Да байта ради, это же твое мнение..
MS>Ну вот видишь. А то политика, милитика
Политическое мнение, иначе ты не стал бы тут сейчас фантастические сценарии строить..

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

MS>Обработка данных — это процесс с их изменением. Если здесь не применять транзакцию, то при прерывании загрузки файла может случиться ситуация с несогласованностью данных.
Ни разу не встречал такого, чтобы нельзя было такую сверхдлинную транзакцию поделить на много маленьких. Нет, бывают, конечно, люди, которые утверждают, что "импорт справочника товаров" должен быть атомарным, но почему-то объяснить происхождение этого требования, бенефит от его выполнения, и каким дизастером чревато невыполнение, они мне так и не смогли.
M>>Вовсе нет. В рамках транспортной транзакции, БД транзакций может быть сколько угодно, но вот если эта транспортная транзакция выполняется в рамках БД транзакции, то здесь явно какой-то косяк...

MS>Ну хоть с первым разобрались Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция. В ее рамках выполняется транспортная.
Ага. Тебе уже написали, что это — косяк. Или я что-то не так понял? Ты намекаешь, что в рамках DB-транзакции можно вызывать MSMQ? Ну так это значит нифига не транспортная транзакция. Транспортная транзакция закончится тогда, когда данные доедут до получателя.

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

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

MS>>Обработка данных — это процесс с их изменением. Если здесь не применять транзакцию, то при прерывании загрузки файла может случиться ситуация с несогласованностью данных.
S>Ни разу не встречал такого, чтобы нельзя было такую сверхдлинную транзакцию поделить на много маленьких.

Я тоже так думаю. Только при чем здесь мой вариант и почему же она получается эдакая сверхдлинная?

S>Нет, бывают, конечно, люди, которые утверждают, что "импорт справочника товаров" должен быть атомарным, но почему-то объяснить происхождение этого требования, бенефит от его выполнения, и каким дизастером чревато невыполнение, они мне так и не смогли.

Про импортирование — возможно асбурд. Но изменение — отнюдь.

M>>>Вовсе нет. В рамках транспортной транзакции, БД транзакций может быть сколько угодно, но вот если эта транспортная транзакция выполняется в рамках БД транзакции, то здесь явно какой-то косяк...

MS>>Ну хоть с первым разобрались Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция. В ее рамках выполняется транспортная.
S>Ага. Тебе уже написали, что это — косяк. Или я что-то не так понял? Ты намекаешь, что в рамках DB-транзакции можно вызывать MSMQ? Ну так это значит нифига не транспортная транзакция.

Почему это? Главное — переслать данные в транзакции. А в рамках чего это будет происходить (хоть в рамках другой транзакции) — это не суть важно.

S>Транспортная транзакция закончится тогда, когда данные доедут до получателя.

Правильно.

Здравствуйте, Mika Soukhov, Вы писали:
MS>COM+ уже поддерживает SOAP. Так что к таким компонентам можно обращаться как к Web Services.

Ой! А можно подробнее...

А то я подумал может тут где-то и решение моей задачи лежит...
Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).
Требуется увидеть его на виндах как базу данных.
Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

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

EXO>Здравствуйте, Mika Soukhov, Вы писали:
MS>>COM+ уже поддерживает SOAP. Так что к таким компонентам можно обращаться как к Web Services.

EXO>Ой! А можно подробнее...

EXO>А то я подумал может тут где-то и решение моей задачи лежит...
EXO>Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).

А что, под Unix уже COM+ портировали?

EXO>Требуется увидеть его на виндах как базу данных.
EXO>Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

Под Windows на чем пишешь? Если .NET, то вообще проблем нет. Добавляшь в проект Add Web Reference....

Здравствуйте, Mika Soukhov, Вы писали:
EXO>>Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).
MS>А что, под Unix уже COM+ портировали?

Почему? Веб сервисы через SOAP. Они там давно есть...

EXO>>Требуется увидеть его на виндах как базу данных.
EXO>>Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

MS>Под Windows на чем пишешь? Если .NET, то вообще проблем нет.
MS> Добавляшь в проект Add Web Reference....

На виндах есть уже готовая прога (не моя), которая работает с базами через OLE DB
Мне надо натравить ее на юниксовую апликуху (которая не есть БД, но может быть так представлена).
А для этого что-нибудь написать... или не писать.

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

EXO>>Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).

MS>А что, под Unix уже COM+ портировали?
А причем тут COM+? Вообще web сервисы и SOAP пришел от Java. И именно из-за того, что его все платформы обязались держать.

EXO>>Требуется увидеть его на виндах как базу данных.
EXO>>Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

MS>Под Windows на чем пишешь? Если .NET, то вообще проблем нет. Добавляшь в проект Add Web Reference....
Я бы сказал не только. В Net достаточно много удобных инструментов для работы с SOAP. Если другая платформа, то Soap Toolkit.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:
MS>>Под Windows на чем пишешь? Если .NET, то вообще проблем нет. Добавляшь в проект Add Web Reference....
GZ>Я бы сказал не только. В Net достаточно много удобных инструментов для работы с SOAP. Если другая платформа, то Soap Toolkit.

Не, с SOAP все понятно. Более того со стороны юниксовой программы у меня исходники есть.
Проблема с виндовой стороны. Мне надо прикинуться стандартным OLE DB! Иначе чужая виндовая прога меня просто не поймет.

Собственно говоря я с удовольствием бы вообще ничего не писал с виндовой стороны. Но не знаю как так выкрутиться.

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

EXO>Не, с SOAP все понятно. Более того со стороны юниксовой программы у меня исходники есть.
EXO>Проблема с виндовой стороны. Мне надо прикинуться стандартным OLE DB! Иначе чужая виндовая прога меня просто не поймет.
EXO>Собственно говоря я с удовольствием бы вообще ничего не писал с виндовой стороны. Но не знаю как так выкрутиться.
А напрямую общаться с web сервисом общаться им впадлу? Написание OleDB provider'a, даже несмотря на ATL helperные классы весьма неприятная вещь. В свое время подолбался.

С уважением, Gleb.

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

MS>>А что, под Unix уже COM+ портировали?

EXO>Почему? Веб сервисы через SOAP. Они там давно есть...

Вообще странно как. Я в исходном сообщении писал про COM+

EXO>На виндах есть уже готовая прога (не моя), которая работает с базами через OLE DB
EXO>Мне надо натравить ее на юниксовую апликуху (которая не есть БД, но может быть так представлена).
EXO>А для этого что-нибудь написать... или не писать.

А какая разница, на чем БД держиться, на видновс или еще что? Пропиши соответсвующий коннекшн стринг и укажи в качестве хоста тот компютер, где у тебя установлен сервер.

Здравствуйте, GlebZ, Вы писали:
GZ>А напрямую общаться с web сервисом общаться им впадлу?

Впадлу. Команда разработчиков того продукта (дельфисты) про веб-сервисы знать не желают.

> Написание OleDB provider'a, даже несмотря на ATL helperные классы весьма неприятная вещь.
> В свое время подолбался.

Вот потому-то мне и не хочется... Но похоже придется.
А то я уж обрадовася, что может есть какой универсальный драйверок,
чтобы веб-сервис представить как Ole DB Provider.

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

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

С уважением, Gleb.