Здравствуйте 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

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