Необходимо проделать следующие манипуляции (или следующую архитектуру):
на сервере есть файл, который должен меняться несколькими клиентами.
Если реализовывать это при помощи COM как это должно выглядеть?
или по другому как создать такую архитектуру:
1. Клиент запускает свой экземпляр сервера
2. Дальше клиент занимается своими делами, а сервер своими
3. Клиент может запросить в произвольный момент времени к-то методы у сервера
4. Сервер в произвольный момент времени должен передать клиенту сообщение об изменении
состояния (изменении содержимого файла например)
5. При закрытии клиента закрывается его экземпляр сервера
-------
как все это сделать? :)

Здравствуйте Аноним, Вы писали:

А>Необходимо проделать следующие манипуляции (или следующую архитектуру):
А>на сервере есть файл, который должен меняться несколькими клиентами.
А>Если реализовывать это при помощи COM как это должно выглядеть?
А>или по другому как создать такую архитектуру:
А>1. Клиент запускает свой экземпляр сервера

Прямо-таки свой собственный? А зачем?

А>2. Дальше клиент занимается своими делами, а сервер своими

Отдельную нитку(и) запускаешь в сервере и делаешь в них то, что нужно.

А>3. Клиент может запросить в произвольный момент времени к-то методы у сервера

Это будет.

А>4. Сервер в произвольный момент времени должен передать клиенту сообщение об изменении
А>состояния (изменении содержимого файла например)

Реализуешь событийный интерфейс, через него оповещаешь клиента (см. COM Events)

А>5. При закрытии клиента закрывается его экземпляр сервера

L>Здравствуйте Аноним, Вы писали:

А>>Необходимо проделать следующие манипуляции (или следующую архитектуру):
А>>на сервере есть файл, который должен меняться несколькими клиентами.
А>>Если реализовывать это при помощи COM как это должно выглядеть?
А>>или по другому как создать такую архитектуру:
А>>1. Клиент запускает свой экземпляр сервера

L>Прямо-таки свой собственный? А зачем?
нуу... я не знаю, например для того что бы уже сервер в свою очередь не заупускал
свои параллельные нитки..
да наверное заморочился..

А>>2. Дальше клиент занимается своими делами, а сервер своими

L>Отдельную нитку(и) запускаешь в сервере и делаешь в них то, что нужно.

возможно ли что бы в сервере нитка была методом этого сервера?
Мне нужно организовать цепь обменов

Сервер-Сервер-Клиенты

А>>3. Клиент может запросить в произвольный момент времени к-то методы у сервера

L>Это будет.

А>>4. Сервер в произвольный момент времени должен передать клиенту сообщение об изменении
А>>состояния (изменении содержимого файла например)

L>Реализуешь событийный интерфейс, через него оповещаешь клиента (см. COM Events)

все таки пункт 2:
несколько клиентов шуршат меняют например БД посредством сервера.. Так вот надо что бы клиент продолжал работать, но своевременно был поставлен в известность об изменениях выполненным другим клиентом.
Критичное требование: не использовать "третьи" приблуды типа MTS...
А>>5. При закрытии клиента закрывается его экземпляр сервера

L>Здравствуйте Аноним, Вы писали:

А>>Необходимо проделать следующие манипуляции (или следующую архитектуру):
А>>на сервере есть файл, который должен меняться несколькими клиентами.
А>>Если реализовывать это при помощи COM как это должно выглядеть?
А>>или по другому как создать такую архитектуру:
А>>1. Клиент запускает свой экземпляр сервера

L>Прямо-таки свой собственный? А зачем?
нуу... я не знаю, например для того что бы уже сервер в свою очередь не заупускал
свои параллельные нитки..
да наверное заморочился..

А>>2. Дальше клиент занимается своими делами, а сервер своими

L>Отдельную нитку(и) запускаешь в сервере и делаешь в них то, что нужно.

возможно ли что бы в сервере нитка была методом этого сервера?
Мне нужно организовать цепь обменов

Сервер-Сервер-Клиенты

А>>3. Клиент может запросить в произвольный момент времени к-то методы у сервера

L>Это будет.

А>>4. Сервер в произвольный момент времени должен передать клиенту сообщение об изменении
А>>состояния (изменении содержимого файла например)

L>Реализуешь событийный интерфейс, через него оповещаешь клиента (см. COM Events)

все таки пункт 2:
несколько клиентов шуршат меняют например БД посредством сервера.. Так вот надо что бы клиент продолжал работать, но своевременно был поставлен в известность об изменениях выполненным другим клиентом.
Критичное требование: не использовать "третьи" приблуды типа MTS...
А>>5. При закрытии клиента закрывается его экземпляр сервера

Здравствуйте Аноним, Вы писали:

А>Необходимо проделать следующие манипуляции (или следующую архитектуру):
А>на сервере есть файл, который должен меняться несколькими клиентами.
А>Если реализовывать это при помощи COM как это должно выглядеть?
А>или по другому как создать такую архитектуру:
А>1. Клиент запускает свой экземпляр сервера
А>2. Дальше клиент занимается своими делами, а сервер своими
А>3. Клиент может запросить в произвольный момент времени к-то методы у сервера
А>4. Сервер в произвольный момент времени должен передать клиенту сообщение об изменении
А>состояния (изменении содержимого файла например)
А>5. При закрытии клиента закрывается его экземпляр сервера

Чтобы для каждого клиента открывался отдельный процесс нужно указать сингл_юз при регистрации сервером фабрики класса или настроить, в dcomcnfg, права на сервер, указав на странице Identity значение "The Launching user" (второй вариант хуже из-за проблем с правами, так как при этом сервер запускается под учетной записью клиента).


Вот только зачем все это нужно? Почему нельзя обойтись одним сервером?

PS

Все же стоит зарегистрироваться, а то когда беседуешь с Аноним возникает ощущение что говоришь со стенкой.

Здравствуйте Аноним, Вы писали:

А>возможно ли что бы в сервере нитка была методом этого сервера?

Нитки (или потоки) вообще не могут быть "методами". По определеную!
Метд мжет выполняться паралельно разными нитками.

А>Мне нужно организовать цепь обменов
А>Сервер-Сервер-Клиенты

С этим проблем быть не должно.


А>все таки пункт 2:
А>несколько клиентов шуршат меняют например БД посредством сервера.. Так вот надо что бы клиент продолжал работать, но своевременно был поставлен в известность об изменениях выполненным другим клиентом.

Для этого нужно или чтобы клиент проверял состояние через определенный промежуток времени (метод не красивый, но самый надежный и легкий в реализации), или реализовать обратную связь, например, через события (IConnectionPointContainer/IConnectionPoint). Метод плохой по двум причинам. 1-я — будут (обязательно!) проблемы с защитой (о том как ее обойти будет сказано в моей статье о защите в DCOM в #0 RSDN Magazine). 2-я — в этом варианте сервер становится заодно и клиентом, причем клиентом (извини за каламбур) всех своих клиентов. Это приводит к тому, что если хотя бы один клиент зависнет, то вызов его методов приведет к повисанию сервера (пусть даже временному, но повисанию). Конечно можно обойти это производя вызовы из отдельных потоков, но это приведет к существенному усложнению кода, и если ваши программисты не очень хорошо знакомы с ком, вероятность того, что этот проект вообще не заработает будет очень велика.

А>Критичное требование: не использовать "третьи" приблуды типа MTS...

Требования совершенно дурацкие. Потому, что COM+ мог бы упростить реализацию данной задача.
А на какие ОС предполагается ставить сервер?

VD>Чтобы для каждого клиента открывался отдельный процесс нужно указать сингл_юз при регистрации сервером фабрики класса или настроить, в dcomcnfg, права на сервер, указав на странице Identity значение "The Launching user" (второй вариант хуже из-за проблем с правами, так как при этом сервер запускается под учетной записью клиента).


VD>Вот только зачем все это нужно? Почему нельзя обойтись одним сервером?

VD>PS

VD>Все же стоит зарегистрироваться, а то когда беседуешь с Аноним возникает ощущение что говоришь со стенкой. :(
я зарегистрирован , просто стесняюсь ламерские вопросы задаваь :)

А>>все таки пункт 2:
А>>несколько клиентов шуршат меняют например БД посредством сервера.. Так вот надо что бы клиент продолжал работать, но своевременно был поставлен в известность об изменениях выполненным другим клиентом.

VD>Для этого нужно или чтобы клиент проверял состояние через определенный промежуток времени (метод не красивый, но самый надежный и легкий в реализации), или реализовать обратную связь, например, через события (IConnectionPointContainer/IConnectionPoint). Метод плохой по двум причинам. 1-я — будут (обязательно!) проблемы с защитой (о том как ее обойти будет сказано в моей статье о защите в DCOM в #0 RSDN Magazine). 2-я — в этом варианте сервер становится заодно и клиентом, причем клиентом (извини за каламбур) всех своих клиентов. :) Это приводит к тому, что если хотя бы один клиент зависнет, то вызов его методов приведет к повисанию сервера (пусть даже временному, но повисанию). Конечно можно обойти это производя вызовы из отдельных потоков, но это приведет к существенному усложнению кода, и если ваши программисты не очень хорошо знакомы с ком, вероятность того, что этот проект вообще не заработает будет очень велика.

А>>Критичное требование: не использовать "третьи" приблуды типа MTS...

VD>Требования совершенно дурацкие. Потому, что COM+ мог бы упростить реализацию данной задача.
VD>А на какие ОС предполагается ставить сервер?
---------
Очень актуальный для меня вопрос!

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

Есть ПО которое работает с этим классом.

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


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

Здравствуйте 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 — лучшее средство.

Здравствуйте Аноним, Вы писали:

А>я зарегистрирован , просто стесняюсь ламерские вопросы задаваь

Ламерскими обычно бывают ответы. Ламеры вопросы задают редко и обычно они звучат так: "Кинте ссылку на ХХХ решающаю мою проблему YYYY".

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

VD>Здравствуйте Аноним, Вы писали:

А>>я зарегистрирован , просто стесняюсь ламерские вопросы задаваь :)

VD>Ламерскими обычно бывают ответы. Ламеры вопросы задают редко и обычно они звучат так: "Кинте ссылку на ХХХ решающаю мою проблему YYYY". ;)
Спасибо за поддержку :)

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 — лучшее средство.
мне кажется — без разницы..

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

INT>а что такого с DAO? что не может ДАО а может ADO в случае с mdb?

Ну, например DAO-курсор не может быть отключен от базы и передан на с сервера на клиентскую машину. Не может полностью использовать возможности SQL-сервер или Oracle. Да и какой смысл использовать технологию на которую поставил крест сам MS?

INT>Кстати, ADO может работать с dbf?

Да. В форуме по базам данных даже был пример подключения...

INT>я понимаю, что "сетевым" оно станет если положить базу на удаленный хард и подключаться к ней..В этом случае оно станет файл-серверным, нам же требуется клиент сервер, т.е. нам не нужно перекачивать таблицы на локал,

Если нужно только оптимизация передачи данных, то я вас разочарую... самый эфективный способ работы с БД — это SQL-сервер, а не многоуровневая парадигма. Последняя нужна для переноса логики на сервер. Она приводит к увеличению накладных расходов (хотя с логальными СУБД вроде Access и Dbase этого почти незаметно).

INT>нам не нужно каждые 5 секунд опрашивать изменения, Сервер сам потревожит нас если интересующие нас надоры были изменены..

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

VD>>Можно воспользоваться специально заточенными под распределенными вычисления Borland MIDAS-ом или нашим
INT>ascDB.

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

Гы-гы. Мы на этот продукт угрохали 20 человеколет. Это приблизительно (по минимуму) 200 Килобаксов. Ваши проблемы с изучением и поддержкой, по сравнению с этим — просто комейки!

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

INT>Вот! Краеугольный вопрос.. Представте себе эдакого тонгокого клиента, в процессе редактирования справочника..

Да, да... вот уже 6 лет педставляю, представляю и никак не могу... Этот тонкий по минимуму на винте 20 мег жрет и тормозит как... а обычный получается ~100 Кб. (извени это, так... на лирику прорезало)

INT>В справочнке (скажем "Товары") 25 тысяч напименований.. Как здесь можно поступить?

В ascDB по умолчанию работает прокручиваемый forward-only-курсор. Может открывать хоть милиард записей. При этом скачивает только те которые запрашивает пользователь (блоками... нажмет пользователь пару раз PgDn... следующий блок приедит...).

Можно сделать и через Web-браузер. При этом опять же через ascDB открыл курсор в сесию бросил и живи спокойно. На других технологиях прийдется повыеживаться, но тоже сделать можно (читать поблочно).

INT>Если использовать на локале чьи то рекордсеты, то какой же это тонкий клиент?

А exe-шник на "локале" будет? Если да, то какой это к черту тонкий клиент?

Система где должна работать? В закрытой сети (локальной или VPN по Инету) или по Инету в public-режиме?

Если первое, то за каким чертом нужен "тонкий" клиент? Если второй, то какие нахрен обратные уведомления?

INT> Если реализовывать самому взаимодействие с сервером — другое дело, т.е. сервер нас извещает по определенной схеме, что данные запрошенные нами претерперли изменение, и мы опрашваем заново набор..

Тонкий клиент не может ни уведомлений принимать, ни действий (не связаных с отрисовкой) выполнять, а рантайм у него 20 мег и выше (IE). Это по терминологии MS, Sun, Oracle...

Рантайм ascDb ~ 2.5 мега. Ставится одним пинком.

Да и за каким чертом клиенту перечитывать данные если пользователь этого не хочет?

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

Да молча. Что там делать. Если клиент "тонкий", т.е. html-страничка, то все действия делаются на Web-сервере. Вызываешь ADO, ascDB, DAO или еще что и добавляешь Insert-ом запись. Ну, требование "сохранив при этом позиционирование на новом товаре" — это какие то ISAM-тые предроссудки. Позиционирование может быть только в курсоре. Вставляй через курсор и будет "позиционирование". Вот только зачет? Код нового товара извсестен!

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

Сервер. Я еще не говорил, что твое понимание "тонкого" клиента малость не совпадает с общепринятым?

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

А как ты хочешь на VC тонкого глиента писать? Не на ActiveX-ах случаем?

Ну, разубеждать здесь безполезно... попробуй спросить, что об этом пункте думают другие.

PS

Дай, плиз, свое определение "тонкого клиента"! А то без этого мы будем говорить на разных языках.

http://www.rsdn.ru/forum/newmsg.asp?mid=23541

Автор: INT
Дата: 23.01.02

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

INT>а что такого с DAO? что не может ДАО а может ADO в случае с mdb?

Ну, например DAO-курсор не может быть отключен от базы и передан на с сервера на клиентскую машину. Не может полностью использовать возможности SQL-сервер или Oracle. Да и какой смысл использовать технологию на которую поставил крест сам MS?

INT>Кстати, ADO может работать с dbf?

Да. В форуме по базам данных даже был пример подключения...

INT>я понимаю, что "сетевым" оно станет если положить базу на удаленный хард и подключаться к ней..В этом случае оно станет файл-серверным, нам же требуется клиент сервер, т.е. нам не нужно перекачивать таблицы на локал,

Если нужно только оптимизация передачи данных, то я вас разочарую... самый эфективный способ работы с БД — это SQL-сервер, а не многоуровневая парадигма. Последняя нужна для переноса логики на сервер. Она приводит к увеличению накладных расходов (хотя с логальными СУБД вроде Access и Dbase этого почти незаметно).

INT>нам не нужно каждые 5 секунд опрашивать изменения, Сервер сам потревожит нас если интересующие нас надоры были изменены..

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

VD>>Можно воспользоваться специально заточенными под распределенными вычисления Borland MIDAS-ом или нашим
INT>ascDB.

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

Гы-гы. Мы на этот продукт угрохали 20 человеколет. Это приблизительно (по минимуму) 200 Килобаксов. Ваши проблемы с изучением и поддержкой, по сравнению с этим — просто комейки!

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

INT>Вот! Краеугольный вопрос.. Представте себе эдакого тонгокого клиента, в процессе редактирования справочника..

Да, да... вот уже 6 лет педставляю, представляю и никак не могу... Этот тонкий по минимуму на винте 20 мег жрет и тормозит как... а обычный получается ~100 Кб. (извени это, так... на лирику прорезало)

INT>В справочнке (скажем "Товары") 25 тысяч напименований.. Как здесь можно поступить?

В ascDB по умолчанию работает прокручиваемый forward-only-курсор. Может открывать хоть милиард записей. При этом скачивает только те которые запрашивает пользователь (блоками... нажмет пользователь пару раз PgDn... следующий блок приедит...).

Можно сделать и через Web-браузер. При этом опять же через ascDB открыл курсор в сесию бросил и живи спокойно. На других технологиях прийдется повыеживаться, но тоже сделать можно (читать поблочно).

INT>Если использовать на локале чьи то рекордсеты, то какой же это тонкий клиент?

А exe-шник на "локале" будет? Если да, то какой это к черту тонкий клиент?

Система где должна работать? В закрытой сети (локальной или VPN по Инету) или по Инету в public-режиме?

Если первое, то за каким чертом нужен "тонкий" клиент? Если второй, то какие нахрен обратные уведомления?

INT> Если реализовывать самому взаимодействие с сервером — другое дело, т.е. сервер нас извещает по определенной схеме, что данные запрошенные нами претерперли изменение, и мы опрашваем заново набор..

Тонкий клиент не может ни уведомлений принимать, ни действий (не связаных с отрисовкой) выполнять, а рантайм у него 20 мег и выше (IE). Это по терминологии MS, Sun, Oracle...

Рантайм ascDb ~ 2.5 мега. Ставится одним пинком.

Да и за каким чертом клиенту перечитывать данные если пользователь этого не хочет?

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

Да молча. Что там делать. Если клиент "тонкий", т.е. html-страничка, то все действия делаются на Web-сервере. Вызываешь ADO, ascDB, DAO или еще что и добавляешь Insert-ом запись. Ну, требование "сохранив при этом позиционирование на новом товаре" — это какие то ISAM-тые предроссудки. Позиционирование может быть только в курсоре. Вставляй через курсор и будет "позиционирование". Вот только зачет? Код нового товара извсестен!

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

Сервер. Я еще не говорил, что твое понимание "тонкого" клиента малость не совпадает с общепринятым?

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

А как ты хочешь на VC тонкого глиента писать? Не на ActiveX-ах случаем?

Ну, разубеждать здесь безполезно... попробуй спросить, что об этом пункте думают другие.

PS

Дай, плиз, свое определение "тонкого клиента"! А то без этого мы будем говорить на разных языках.