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

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

Какой конкретно?

INT>Вот моя ситуация:
INT>Есть некий класс который добавляет, извлекает, менят данные в БД посредством скажем DAO.

DAO — это совсем зря. Это все равно, что поставить в современную Таёту движок от замечательного форда, но 1917 г. выпуска. Его как минимум некому обслуживать будет.

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

Похоже вопрос поставлен не верно. Сетевым оно будет если БД положить в сетке (даже DBF-ную) и подключаться к ней с удаленных машин. Причем замена DAO на Oracle (если не использовать его триггеров) даст только повышение производительности (т.е. ничего с архитектурной точки зрения).

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

INT> Я понимаю, что можно делать это средствами DAO, но хотелось бы вариант в котором этот самый враппер выполняется на сервере, отслеживая изменения и оповещает об этом клиентов..

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

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

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

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

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

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

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

COM здесь является только одним из протоколов позволяющих общаться клиенту и серверу...

INT>Достаточно просто основных вех — конкретных примеров не нужно.
INT>ОС — win32, инструмент — родной VC;

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