VFP&&&&____И потом, такой подход я использую если БД есть ДБС + ДБФ, но так же если БД есть Оракл
Если приложение пишется на FoxPro, то вот это "и для DBF и для ORACLE " - в корне неверный подход.

Котлеты отдельно, а мухи отдельно.

Oracle - клиент - сервер
DBF - файл - сервер

Писать приложение на DBF по технологии клиент-сервер - это создавать себе большие проблемы. Не предназначены таблицы для этого. Как элемент приложения (LOCAL VIEW) - это можно, но писать так ВСЕ приложение - не стоит.

VFP&&&&____
если честно я как-то не представляю КАК можно иначе писать?
ну разве что явно открывать таблицы USE.. shared но тогда ж падения базы может быть запросто...?

У Вас какие-то странные представдения о том, как работает FoxPro с таблицами и почему происходит падение баз. Вкратце. От того, что таблицы открыты по USE они упасть не могут!

Кстати, если уж Вы делаете Local View, то не обращали внимание на "странный" факт, что открытие View автоматически открывает и все таблицы-источники, на основании которых он был построен. Т.е. Вы делаете все тот же USE. Только неявно.

VFP&&&&____ ВладимирМ
Писать приложение на DBF по технологии клиент-сервер - это создавать себе большие проблемы. Не предназначены таблицы для этого. Как элемент приложения (LOCAL VIEW) - это можно, но писать так ВСЕ приложение - не стоит.
а нельзя ли по-подробней в чем собственно проблема, что я делаю неверно? да, конечно возни в написанием запроса и присвоением контролам формы результатов больше чем если б напрямую грид вязать к таблице но все же.. возня - это ИМХО не проблема :-)


Прежде всего, что такое технология клиент-сервер? Серверу посылается инструкция, он эту инструкцию выполняет и возвращает результат клиенту. Т.е. сервер - это "черный ящик". Что там и как работает нас совершенно не интересует.

С файл-сервером все с точность наоборот. Принципиально важным является именно способ обработки.

Просто разная стратегия работы.

Вы ведь рассмотрели только "верхушку айсберга". Т.е. получение выборки. Да и то, в весьма примитивной интерпретации - "я могу всегда сделать выборку", подразумевая под этим команду Select-SQL.

Во-первых, далеко не всегда можно сделать выборку именно командой Select-SQL. Иногда надо задействовать более сложные алгортимы получения выборки.

Во-вторых, если речь идет об одной записи, то зачем вообще городить Local View? Не проще ли сделать примитивный SEEK с последующей буферизацией?

Т.е. получается, что сделать выборку командой Select-SQL не всегда возможно и не всегда нужно.

Далее, если пойти "вглубь", то ведь сброс изменений в таблицы из выборок - это все те же прямые операции записи с таблицами. Да, иногда лишний слой в виде Local View просто необходим, но работать исключительно через них только потому, что хочется делать "как в клиент-сервере" глупо.

Нужно исходить из принципа разумной достаточности. Лишняя копия данных (выборка) должна создаваться тогда, когда это действительно необходимо.

Hor_netКонтролам формы значения присваиваю на этапе редактирования. Во всяком случае для заголовочной части документа. Просто при открытии формы зачитываю заголовок в курсор а потом делаю SCATTER NAME ThisForm.NewValues MEMO. А controlsource имеют значения ThisForm.NewValues.date, ThisForm.NewValues.number? ну и т.п.
Это просто нет слов! Действовать по принципу "зачем просто, если можно сложно". Не просто сделать выборку, но еще и SCATTER из этой выборки! Сильно подозреваю, что Вы так и не поняли, что такое буферизация при переходе от FPD к VFP

Hor_netСобственно все эти буферизованные таблицы это тоже самое только в составе VFP. Но плохи они тем, что если будете переходить на КС, то приделтся все переписывать. А когда свое, то легко заменить одно на другое.
Не получится. Это Вам только кажется, что Вы "обманули" файл-сервер и написали приложение "а-ля клиент-сервер". Если покопаться в коде, то выплывут все "родимые пятна" файл-сервера. Слишком уж большой соблазн напрямую обратиться к таблице и сделать в нее запись вместо предварительной выборки с тщательно прописанными INSERT и UPDATE.

Вряд ли Вам удалось написать что-то вроде "трех-уровневого" приложение (роль среднего слоя выполняют все Ваши выборки, исключающие прямое чтение-запись DBF-таблиц). Т.е. в принципе, это конечно, возможно, но очень сложно и тяжеловесно.

Igor Korolyov
Так что зря ты так наехал на КС идеологию...

Я наехал не на КС идеологию, а на абсолютизацию идеологии.

Почему я должен делать ВСЕ именно в КС идеологии, если вот в данном месте мне удобнее использовать прямой доступ к таблице?

Т.е. мне запрещено использовать SEEK, LOCATE, SCAN по исходной таблице (DBF)? Я должен всегда делать Select-SQL? С какой стати?