Логика работы и написания кода зависит от принятой идеологии построения приложения. Приведенный пример основан на одной из многих идеологий работы. В данном случае - процедурной идеологии.

Процедурный подход подкупает своей простотой. Это "линейный" алгоритм. В данном случае подчиненная форма обязательно должна быть модальной (WindowType = 1 - Modal) и работать в той же DataSession, что и главная (DataSession = 1 - Default Data Session).

По сути, происходит работа как бы с одной формой, "фрагмент" которой оформляется как другая форма.

Что такое буферизация смотри во вложенном файле.

Общая логика данного примера такова: в главной форме накладывается буферизация на таблицу-источник, а в подчиненной форме происходит модификация этого буфера с последующим его сбросом (по команде TableUpdate()).

В подчиненной форме можешь использовать сколько угодно ComboBox. Единственное ограничение - при строковой буферизации (CURSORSETPROP ("Buffering", 3,"exams")) нельзя перемещать указатель записи в таблице exams до завершении редактирования, поскольку это приведет к автоматическому сбросу буфера.

В принципе, в данном примере кое чего не хватает, а кое-что лишнее.

Но вообще-то, прежде чем что-то писать дальше хотелось бы уточнить в какой идеологии предполагается работать.

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

Идеология объектного программирования - форма для редактирования - самодостаточна. Факт изменения в ней данных напрямую не зависит от факта открытия/закрытия других форм. Допустимо переключаться в любую другую форму в любой момент времени.

То что ты описал, это нечто среднее между объектным и процедурным подходом. Причем ближе к процедурному.

К сожалению (а может, к счастью), "стандартного" варианта не существует. Впрочем, кое что общее есть. Чуть позже попробую описать. Иногда и работать надо

Посмотри вложенный файл. Запуск через главный стартовый файл exams.prg

Там все достаточно примитивно сделано. Самый простой вариант. Все написано на VFP6SP5

Что означает префикс (буква) "m." перед именем

Цель процедуры NewId - это генерация автоинкремента. Она запоминает последний использованный номер и при создании новой записи автоматически формирует новое значение ключевого поля. Вовсе не обязательно, что последний использованный номер в настояще время реально существует.

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

Посмотри структуру твоих таблиц. Я во ВСЕ таблицы добавил новое ключевое поле, в свойстве Default которого происходит вызов хранимой процедуры NewId().

Значение по умолчанию (Default)

Ключевое поле играет особую роль при организации ссылочной целостности данных.

Ключевое поле

Начиная с версии VFP8 был введен новый тип данных Integer-Autoincrement. Точнее, это конечно не тип данных, а некое дополнительное ограничение, накладываемое на тип данных Integer. Так вот, это тип данных как раз и выполняет ту же функцию, но другими средствами.

AutoIncrement

criptonПравда я сознательно шел на отказ от модели, основанной на суррогатных ключах. Понятное дело, что среди студентов вполне возможны однофамильцы и даже полные тезки. Однако для упрощения конструкции определяется бизнес-правило, что ФИО уникально в пределах данной БД.
Зря. Суррогатный ключ незначительно усложняет структуру базы данных, но значительно упрощает сопровождение и модификацию базы данных. А также поддержание ссылочной целостности.

Примеров проблем при использовании в качестве ключа ФИО - "вагон и маленькая тележка". Начиная от однофамильцев и кончая удалением и вставкой одной и той же фамилии.

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

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

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

criptonнасколько я понял, твоя реализация тоже частично процедурная,частично основанная на ХП. А какова реализация объектной идеологии? Создание некоего управляющего класса, который берет на себя "разруливание" ситуации?
В целом, именно так. Только цель этого управляющего класса несколько иная.

Подчиненная форма уже независима. Ей вобщем-то, все-равно, будет открыта родительская форма или нет. Она получила входной параметр - код записи. Вот эту запись она и обрабатывает.

В родительской форме необходимо просто сделать обновление картинки по факту модификации в подчиненной форме. Сейчас это сделано "процедурным" способом. Просто ждем окончания работы подчиненной формы.

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

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

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

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

criptonВот здесь немного не догнал. В твоем коде вроде нигде явно не указывается тип буфферизации, тем неменее все работает. Как такое получается и почему? :-)
Указывается. Причем именно явно.

Это надо смотреть в DataEnvironment подчиненной формы. Свойства объектов Cursor.BufferModeOverride = 5

При этом, режим буферизации таблиц главной формы остался без изменений. Т.е. там таблицы вообще не буфферизированы. Поскольку подчиненная форма работает в Private DataSession, то такое разделение возможно.

Получается независимые сеансы данных. Один - в главной форме и другой - в подчиненной. Данные одной формы практически не зависят от данных другой формы.

Cyv авторПравда с суррогатными ключами тоже возможны проблемки. В следствие уникальности записи с суррогатным ключем (если оно автоинкрементно) есть опасность ввода вторичной записи с подобными данными.
А вот об этом недавно напоминал один уважаемый товарищ.
О том что вводя суррогатный ключ, про естественный
ключ не следует забывать, и наложить на него индекс типа Candidate
(возможно с фильтром NOT DELETED()).
Во-первых, получить дубль суррогатного ключа - невозможно. Мы его сами генерируем, сами и должны организовать генерацию так, чтобы этого не случилось.

Чтобы исключить такое событие с гарантией, вводят индекс типа Primary по ключевым полям. Этот индекс по самой своей природе исключает возможность появления дублей.

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

Естесственный ключ - для облегчения просмотра (отображения) информации. Информация для пользователя

Суррогатный ключ - для обеспечения ссылочной целостности базы данных. Информация даже не для программиста, а для функционирования системы.

cripton
Я вполне понимаю назначение суррогатного ключа

...

Имеется таблицы Категория(мастер) и Товар(деталь)
Товар может принадлежать одной и только одной категории
в категории может быит множество товаром, а мгет и не быть вообще - пока не завезли.

Так вот в каждой таблице к качестве ключа использовался счетчик
уникальность на название товар не отслеживалось

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

Потом я конечно понял, как избежать подобных ошибок. Но как иллюстрация к вопросу обсуждения может послужить:-))
Это как раз иллюстрирует тот факт, что Вы не вполне понимаете назначение суррогатного ключа.

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

Назначение суррогатного ключа - это однозначная идентификация записи таблицы. Все.

Причем под термином "запись" в данном случае понимается не "сущность" (товар), а именно физическая запись. "Набор байтов" на диске. Некая "область памяти". Содержимое этой "области памяти" не имеет никакого значения.

А вот чтобы избежать дублей среди "сущностей" вводятся естесственные ключи. Как раз о них и говорил Cyv .

Во всех определениях типа "Суррогатный ключ", "Естесственный ключ", Primary Key, Foreign Key содержится слово "ключ". Все эти термины об одном и том же . Об обеспечении ссылочной целостности.

Добавочное прилагательное призвано всего-лишь подчеркнуть некоторую особенность создания или применения данного ключа.

Primary, Foreign - это указание на область применения
Суррогатный, Естесственный - это указание на способ формирования

При этом, когда говорят о Суррогатных или Естесственных ключах всегда неявно подразумевают, что речь идет именно о Primary.

Цель Primary key - это однозначная идентификация записи. "Естесственный ключ", в общем случае, этого обеспечить не может. Почему? Обсуждалось многократно. Поищите здесь и на форуме по MS SQL. Поэтому ИНН не может служить PK для идентификации организации (а про ИНН писали еще больше)