Еще раз. Видимо и для IgorNG

Если таблица включена в контейнер базы данных, то нигде и никоим образом, путь доступа к этой таблицы FoxPro сам не прописывает. Т.е. мастера пути доступа к таким таблицам не указывают .

Все таблицы, включенные в контейнер базы данных, ищет этот самый контейнер. Он сам "знает" где эти таблицы находятся. У него "внутри" эти самые пути доступа записаны. Соответственно, все мастера FoxPro прописывают путь доступа только и исключительно к контейнеру базы данных. К файлу DBC.

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

Путь доступа к таблицам DBF в контейнере базы данных записан относительно той директории, где расположен сам контейнер. А вот путь доступа до контейнера в DataEnvironment записывается относительно той директории, которая была текущей на момент добавления таблицы в DataEnvironment.

------------------------------------------------------------

По поводу Local View.

Local View - это объект контейнера базы данных. Он физически находится внутри самого контейнера. Внутри DBC. Как следствие, никаких путей доступа он вообще НЕ ХРАНИТ . Зачем ему знать эти пути, если он сам "живет" внутри того объекта, который использует?

-----------------------------------------------------------

По поводу ошибки.

Здесь явно и однозначно произошло закрытие Local View или переход в другую DataSession. Кроме явных способов закрытия, существуют еще и не явные. Например, открытие таблицы в рабочей области, где ранее была открыта другая таблица автоматически закроет эту самую другую таблицу. Молча. Без каких-либо сообщений об ошибках.

Поскольку самой формы мы так и не увидим, то гадать как же именно произошло это закрытие можно долго и безуспешно. Либо прикладывайте форму во вложении, либо ищите ошибку сами.

Запустить формы на исполнение, чтобы получить ошибку - невозможно. В архиве нет много чего. Если судить по коду, то, вроде бы, ничего такого, что могло бы привести к закрытию представления WHOMISP в приложенных файлах нет. Но!

- Подчиненная форма создана с использованием библиотеки классов baseobj.vcx. Что именно написано в этой библиотеке - не известно
- Подчиненная форма НЕ модальная (если только это не указано в библиотеке baseobj.vcx). Это значит, что возможен переход в какие-либо другие формы, где и могло произойти закрытие представления
- Из подчиненной формы могут быть вызваны еще две формы: форма календаря (do form kalend) и форма сообщений (DO FORM frmYesNo). Ничего не известно о работе с данными в этих формах
- Сильно подозрительно выглядит вызов форм изнутри Grid. Крайне желательно перед вызовом форм сделать явный переход (через setFocus()) на другой объект формы
- Из описания ошибки не ясно, проблема возникает только после вызова подчиненной формы? Или же достаточно просто перейти на 3 закладку, пощелкать там по Grid и вернуться на 2 закладку, чтобы "потерять" WHOMISP


Я бы написал в окне Watch() отладчика функцию USED("WHOMISP") и поставил слева от нее точку останова. В этом случае, произойдет автоматический переход в окно отладчика, если значение этой функции изменится. Понятно, что первый переход произойдет в момент открытия формы. Но зато когда произойдет закрытие представления, также будет выполнен переход в окно отладчика и можно будет увидеть, какой именно метод вызвал закрытие.

Ну, видимо в процессе расстановки или удаления MessageBox() что-то все-таки было изменено в формах.