Для начала следует очень серьезно обдумать необходимость программного создания Local View.

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

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

Команды CREATE - это команды проектирования . В работающем приложении они крайне не желательны. Не стоит этого делать, особенно в начале изучения среды FoxPro.

View должны создаваться один раз при проектировании базы данных и их структура не должна меняться на протяжении всего времени работы приложения.

Вы вообще можете объяснить, хотя бы самой себе, ЗАЧЕМ Вам понадобилось программно создавать View?

Вообще-то, именно для INNER JOIN есть альтернативное решение вопроса связи полей в дизайнере.

1. Убрать все связи с закладки JOIN
2. Создать соответсвующие связи на закладке Filter.

Т.е. запрос получится вида

SELECT ...
FROM Tab1, Tab2, Tab3 ...
WHERE Tab1.Id1 = Tab2.Id1 AND Tab2.Id2 = Tab3.Id2 ...

Это абсолютно то же самое, что и INNER JOIN. Просто другой синтаксис.

Только, как мне кажется, Вы выбрали заведомо не удачное решение. Не должен запрос содержать столько таблиц-источников. Вы получите дикие тормоза. Думаю, надо "в консерватории что-то подправить". Либо написать свой собственный класс для фильтрации, либо "научить" чужой класс фильтровать данные нужным Вам способом, либо изменить интерфейс приложения.

Собственно, попробуйте описать задачу, а не придуманный Вами способ ее решения. Как Вы вообще представляете себе работу с Grid у которого такое количество столбцов?

В процессе редактирования отображаются данные только по одному пациенту? Т.е. стоит задача выбрать некоторые реквизиты одного пациента или выбрать пациентов по некоторым реквизитам?

Задачи ввода данных и анализа данных - это две принципиально разные задачи. И не надо их смешивать. Они решаются разными методами и в разных интерфейсах. Как правило, даже в разных продуктах (программах).

Интерфейс определяется логикой процесса. Т.е. а как вообще пользователь ищет нужное место для ввода изменений? ЧТО он ищет? Как формулируется задача для ввода данных?

У пациента Х, при проведении обследования Y, установлены результаты Z? Правильно?

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

Ну например, если одно и то же обследование делали несколько врачей, то по значению результата невозможно сказать какой врач делал обследование и у какого пациента. Напомню, речь идет о заведении данных. Их еще нет. Поэтому нечего сравнить или сопоставить, чтобы сделать выводы.

А раз имеем последовательный процесс отбора, то его и надо реализовывать последовательно . В отдельных элементах (Grid). Не пытаясь свалить всю имеющеюся информацию в одну кучу.

Пользователь будет последовательно "спускаться" по иерархии критериев (по таблицам) и нет никакой необходимости отображать все таблицы сразу. В одном Grid. Можно распологать их рядом на одной форме или в разных формах. Это как будет удобно.

- Отдельный Grid на список пациентов по его личной информации (номер карточки, ФИО и т.п.)
- Отдельный Grid на список обследований одного (найденного) пациента (Какой обследование, когда)
- Отдельный Grid на список результатов одного (найденного) обследования

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

Тут важен сам принцип. Мы не сваливаем все в одну кучу (в один Grid). Мы разделяем данные по разным Grid. По сути, стремимся отображать данные максимально близко к тому, как они хранятся в базе данных.

АленаШПоэтому есть

1.) Личные данные tabl1: ФИО, дата рождения, адрес.

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

3.) И уже отдельно - результаты Tabl3- там только код исследования и результаты.

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

Так вот сейчас речь идет только о Tabl2 и расшифровке. Мой предшественник в Tabl2 хранил и все расшифровки, параллельно с таблицами-кодификаторами. Я считаю это абсолютно неправильным подходом к хранению данных, к раздуванию БД. А зачем тогда кодификаторы? Или опять я не права?
Да нет. Все правильно. За исключением того, что нет необходимости цеплять в итоговый Grid данные из первой или третьей таблиц. Поскольку с конкретной записью из первой таблицы уже определились, а данных из третьей таблицы еще попросту нет. Вопрос только в том, как организовывать поиск.

Есть несколько стратегий:

1. То, что сделал Ваш предшественник. Дублировать данные из справочников (кодификаторов) в списке обследований.

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

2. Отображать в Grid не только "расшифровку" кода, но и сам код.

"Расшифровку", разумеется, брать из справочника и по ней поиск в Grid невозможен. А вот сам код брать из таблицы обследований и по ней поиск возможен. Вы удивитесь, насколько быстро пользователи выучат эти внутренние коды.

Хотя, конечно, теоретически, пользователь не должен видеть эти внутренние коды, поскольку их основное назначение - это обеспечение внутренней ссылочной целостности. Но реальная задача - это всегда компромис. Баланс между тем как должно быть "по правилам" и тем как "оптимальнее". Все зависит от того, что вкладывается в понятие "оптимальнее".

3. Изменить способ поиска (фильтрации) нужных данных. Здесь вариантов огромное количество. Все зависит от фантазии разработчика.

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

Кстати, не вижу никаких проблем накладывать фильтр и на связанные таблицы.

А так: