Local View - это НЕ таблица. Физически - это обычная команда Select-SQL.

Теперь, представь себе, что в программе ты написал команду

SELECT Field1, Field2 FROM MyTab

А потом взял и удалил из таблицы MyTab поле Field1. Т.е. этого поля в таблице просто не стало. Физически. Как именно должна прореагировать программа на такое действие? Правильно, "обложит" тебя нехорошими словами.

На все это накладывается еще то, что ты, видимо, редактируешь Local View через дизайнер. Т.е. вступают в силу еще дополнительные ограничения, налагаемые самой программой-дизайнером.

Так что здесь все "как положено". Вовсе это не "хлипкая конструкция". Просто ты сам же разрушаешь основу, на которой она построена. Претензии не по адресу. Надо тщательнЕе проектировать структуру базы данных.


Делать Local View на базе другого Local View можно. Но опять же, следует понимать, что именно ты делаешь. Физически - это означает 2 последовательных SQL-запроса. Ну, что-то вроде:

SELECT * FROM MyTab INTO CURSOR View1 NOFILTER READWRITE
SELECT * FROM View1 INTO CURSOR View2 NOFILTER READWRITE

Т.е. сам понимаешь, получить View2 невозможно, если предварительно не создать View1. FoxPro это проделает автоматически при первом открытии View2. Но вот для того, чтобы обновить содержимое View2 придется сначала обновить содержимое View1.

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

Тихо сам с собою ?... Ты хоть дай цитаты к которым ты эти вопросы задал. На что отвечать-то?

men deaВ1. Из этого что, следует вывод ...
Из чего из этого? В любом случае, вывод неправильный. Тем более можно редактировать код SQL-запроса напрямую в дизайнере View (это можно делать в VFP9)

men deaВ2. Интересно где?
Интересно что?

men deaВ3. И как напрямую делать LV, минуя посредников, разве что не "денормализуя" БД?
Зависит от версии FoxPro и постановки задачи. Далеко не всегда необходимо именно Local View.

Кроме того, если я написал "если есть возможность", не надо понимать это как "обязательно".

Физически, само Local View хранится в контейнере базы данных (файле DBC). При модификации Local View замена происходит по типу "удалить все/создать заново" так что в самом определении Local View ничего от старого определения остаться не может.

Но это только в том случае, если на базе изменяемого Local View не было сделано другого Local View. В этом случае в дочернем Local View ничего изменено не будет. Соответственно, попытка открытия дочернего Local View вызовет сообщение об ошибке.

Т.е., если есть "иерархия" Local View то необходимо начать изменение структуры с дочерних Local View. Сначала удалить из них ссылки на те поля, имена которых предполагается изменить. Затем проделать то же самое с родительским Local View. Когда не останется ссылок на эти изменяемые поля провести собственно модификацию в исходных таблицах. Затем восстановить ссылки уже на новые поля.

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

В режиме модификации контейнера базы данных это пункт меню DataBase - Clean Up DataBase

или программно:

OPEN DATABASE MyBase EXCLUSIVE
PACK DATABASE


Если мне нужен Local View то я делаю его через дизайнер. Никаких дополнительных "телодвижений" делать не надо.