Уважаемый FoXXX
Я не прощу от вас конкретных примеров!
Мой вопрос именно про идеологию построения системы.
Дело в том, что я на работе занимаюсь именно идеологией взаимодействия клиента и сервера.
Я в свое время (примерено лет 5 назад) отказался от построения универсальной клиентской системы, которая могла бы работать с ЛЮБЫМ сервером баз данных и в качестве сервера выбрали MS SQL Server. По этой причине у меня нет необходимости писать свой серверный код с строго в ANSI-92. Также я могу использовать SQL Pass-Through (PT) без всяких ограничений.
Вы выбрали, как я понял из ваших сообщений в этом топике, вариант с использование для извлечения и обновления существующих данных Remote View (RV).
При этом, из ваших же сообщений, я делаю вывод, что в качестве исходных данных для построения RV вы используете не только таблицы сервера, но и объекты View сервера. Это нормально и вполне логично, т.к. построитель RV самого VFP не в состоянии построить запрос для удаленного источника данных даже в соответствии с ANSI-92!.
Т.е. у вас в формах клиента (VFP) есть данные, полученные через такие RV, которые отображают данные из нескольких таблиц, т.к. View как объект базы данных сервера может почти тоже самое, что и запрос, т.е. содержать конструкции вида JOIN, UNION, GROUP BY. Не так ли.
Далее вы писали, что обновление данных на севере вы производите через RV с использованием команды VFP - TABLEUPDATE(...).
И вот тут у меня возникает большой вопрос! Каким образом вы производите обновление данных на севере через RV (TABLEUPDATE) в случае, когда в качестве источника данных для вашего RV послужил View сервера, а не таблица? Да не просто View, а View, который построен от нескольких таблиц.
При попытки обновить такое поле вы получите сообщение типа "Update or insert of view ..... failed because it contains a derived or constants field". Думаю, что переводить это не надо.
А в реальной системе, у вас все таблицы (ну за исключением, может быть "плоских" таблиц-справочников, т.е. таблиц, которые не имеют НИ одного Foreign Key) имеют связи с другими и с помощью View вы их и "собираете".
Как вы в таком случае обновляет RV в клиенте?
Если через хранимые процедуры сервера, т.е. через SQLEXEC, т.е. через PT, то тогда система у вас точно не будет универсальная и работать с любым ANSI-92 совместимым сервером баз данных.
Хотелось бы услышать от вас, как идеолога системы ответы на мои вопросы.

С уважением, Алексей

Если строить запрос через Local View, то ограничения, как я полагаю, те же, что и в Remote View, но я ни разу не пользовался Local View :).
Если мне надо сделать запрос, то использую команду SELECT - SQL самого VFP. А в ней с каждой версией все больше соответствия наблюдается со стандартом ANSI-92. И это рабует!
Собственно говоря, как я полагаю, в этом одно из огромных достоинств VFP перед другим, как клиента сервера баз данных. Есть свой RDBE (Relation DataBase Enagine), который почти полностью соответствует ANSI-92. Можно гибко разделять нагрузку между севером и клиентом.
Поэтому, лет 6 назад мы на фирме и выбрали его (VFP) в качестве инструмента написания клиентской части для КИС (Корпоративной Информационной Системы).

С уважением, Алексей

FoXXXАлексей! Вы используете нормализацию? какую?

Вам много приходится собирать?
1. Да, конечно, 3N - 3-я нормальная форма.
2. А практически все запросы у нас следуют не к таблицам, а к View
С уважением, Алексей.

FoXXXсхема такая:
RV1+RV2 -> LV1
RV3+RV4 -> LV2
RV1+RV4+LV1 -> LV3
LV1+LV2-LV3 -> LV4

вот и все... чтобы изменения вступали в силу нужны ключевые поля участников в результате.. и Send SQL Updates например Key Fields Only
Update Using SQL UPDATE
Другим словами, RV1, RV2, RVN - это View только к одной таблице?
С уважением, Алексей.

Все таки хотелось бы глянуть на пример:
У вас на SQl Server есть View, котрый объединяет 3 таблицы:
1. Документ
2. Два справочника на котором есть ссылки в документе.
Есть View на сервере, который объединяет эти три таблицы.
Как вы будете строить LV и RV?
С уважением, Алексей