INT>>Очень актуальный для меня вопрос!

VD>Какой конкретно?
по теме:)

VD>DAO — это совсем зря. Это все равно, что поставить в современную Таёту движок от замечательного форда, но 1917 г. выпуска. Его как минимум некому обслуживать будет.
а что такого с DAO? что не может ДАО а может ADO в случае с mdb?
Кстати, ADO может работать с dbf?

INT>>назовем этот класс враппером.
INT>>Есть ПО которое работает с этим классом.
INT>>Как такое ПО сделать многопользовательским,сетевым?

VD>Похоже вопрос поставлен не верно. Сетевым оно будет если БД положить в сетке (даже DBF-ную) и подключаться к ней с удаленных машин. Причем замена DAO на Oracle (если не использовать его триггеров) даст только повышение производительности (т.е. ничего с архитектурной точки зрения).
я понимаю, что "сетевым" оно станет если положить базу на удаленный хард и подключаться к ней..В этом случае оно станет файл-серверным, нам же требуется клиент сервер, т.е. нам не нужно перекачивать таблицы на локал,
нам не нужно каждые 5 секунд опрашивать изменения, Сервер сам потревожит нас если интересующие нас надоры были изменены..

VD>Вот если на сервере нужно выполнять некие алгоритмы, то это другое дело. Вот здесь появляется ниша для распределенных архитектур, таких как DCOM/COM+, CORBA, RMI, .Net-ремоутинг, Web-сервисы...

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

INT>> А еще лучше если этот самый враперр будет возвращать только результатирующие наборы данных,

VD>Ну, это в распределенных архитектурах вещь сама-собой разумеющаяся.
VD>При этом нужно только определиться в каком виде передавать данные.

VD>Так можно просто засунуть их в массив.
VD>Можно сделать коллекции и передавать все в ОО-виде (но будет или не эффективно или много геморроя по оптимизации передачи)
VD>Можно попользоваться ADO-recordset-ом. При этом делается моментальный снимок данных. Его можно передать на клиента и обратно. Тоже можно достичь использую DataSet из .Net.
VD>Можно воспользоваться специально заточенными под распределенными вычисления Borland MIDAS-ом или нашим
ascDB.

Я ознакомился с этим продуктом.. Вся фишка в том, что в продукте не надо использовать разработки сторонних производителей, это и финансовые и трудовые затраты на приобретение и поддержку..

INT>>а не гонять все таблицы по сети — собственно для этого и делается вся кухня :)

VD>Собственно этим занимаются сегодня многие. И мы в том числе. Ссылку я уже дал...

Вот! Краеугольный вопрос.. Представте себе эдакого тонгокого клиента, в процессе редактирования справочника..
В справочнке (скажем "Товары") 25 тысяч напименований.. Как здесь можно поступить?
Если использовать на локале чьи то рекордсеты, то какой же это тонкий клиент? Если реализовывать самому взаимодействие с сервером — другое дело, т.е. сервер нас извещает по определенной схеме, что данные запрошенные нами претерперли изменение, и мы опрашваем заново набор..
А теперь ситуация "Добавить новый элемент"... В БД используется некий механизм автонумерации, как в случае тонкого клиента реализовать добаление нового элемента (не используя на локальной машине никаких адо) сохранив при этом позиционирование на новом товаре, нои получив код из БД?


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

Получение и отображением.. А кто же занимается добавлением и обновлением?

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

на счет этого чуть выше ...

VD>COM здесь является только одним из протоколов позволяющих общаться клиенту и серверу...
я понимаю...
VD>VC — инструмент хороший, но вот работать на нем с БД и бизнес логикой довольно сложно. Уровень абстракции не тот. Мы, например, делаем прикладной код на VB6. В ближайшее время будем переходить на .Net (C#). Можно тоже и на Дельфи делать, но VC — это чересчур. Зато когда нужно компоненты низкоуровневые писать, то VC — лучшее средство.
мне кажется — без разницы..