помогите! -> скрестить ADO и ADO.NET

Дано:

к старой системе, написанной на VB6/ADO будут добавляться новые модули на C#/ADO.NET. Хотелось бы частично переиспользовать имеющуюся старую функциональность.

Надо:

обеспечить транзакционность. Чтобы процедура на C# (обновляющая какие-то данные) могла в ходе своей работы дернуть процедуру на VB (обновляющую какие-то данные) и все это соответственно коммитилось или роллбэчилось вместе...

Constraint:

Приложение класса desktop, классический клиент-сервер, и должно таким и остаться.

Буду благодарен за любые разумные идеи :)

Все апдейты продолжайте делать на ADO. А из С# получайте данные в виде object[,] и конвертите их в Recordset'ы. Первое что пришлов в голову.

создать свою имплементацию IDbConnection (и иже с ним) на базе "старого" ADODB.Connection никто не пробовал? Что по этому поводу думаете?

Если очень дорог старый добрый ADO - добавь референс на adodb к своей сборке и работай с объектами ADO как и раньше. Зачем огород городить ?

ooops

Если очень дорог старый добрый ADO - добавь референс на adodb к своей сборке и работай с объектами ADO как и раньше. Зачем огород городить ?

хочется, например, цеплять гриды, которые понимают DataSets etc.. Старый добрый АДО сам по себе не дорог, интересно заставить старые куски работать с новыми в рамках одной транзакции.. Для этого самым прямым путем выглядит заставить их шарить один connection..

И .net контролы и поддержка транзакзакций - это достаточно широко :) Напиши (или найди готовый в internet) переходник DataTable <-> Recordset

Системы такого рода (VB6 + C#) - это переходной этап, когда жалко и нецелесообразно выбрасывать старое и делать все снова на др. технологии. Но это только этап ...

Тот, кто принимал решение о таком гибриде - какими мотивами руководствовался ?? Зачем вообще это нужно ??

>Если очень дорог старый добрый ADO - добавь референс на adodb к своей сборке и работай с объектами ADO как и раньше. Зачем огород городить ?

тов. ooops совершеннно прав!

>хочется, например, цеплять гриды, которые понимают DataSets etc.. Старый добрый АДО сам по себе не дорог, интересно заставить старые куски работать с новыми в рамках одной транзакции.. Для этого самым прямым путем выглядит заставить их шарить один connection..

а в старый добрый запорожец двигатель от самолёта не пробовали ввернуть?
Шайтан

повторюсь

Дано: к старой системе, написанной на VB6/ADO будут добавляться новые модули на C#/ADO.NET. Хотелось бы частично переиспользовать имеющуюся старую функциональность. Надо: обеспечить транзакционность. Чтобы процедура на C# (обновляющая какие-то данные) могла в ходе своей работы дернуть процедуру на VB (обновляющую какие-то данные) и все это соответственно коммитилось или роллбэчилось вместе...

переписывать ВСЮ систему целиком (5 млн. строк кода на VB6) - ОЧЕНЬ дорого. Потому, безусловно, имеет смысл искать возможность постепенного перехода на новые технологии и, следовательно, возможность на какой-то переходный период обеспечить совместную транзакционную работу старого и нового кода. Экономический эффект такого решения - миллионы $, так что овчинка безусловно стоит выделки, игра - свеч и т.п.

Засим предлагаю перейти к более конструктивной дискуссии :)