На самом деле проблема решена на половину. Как я указал ранее, если не создавать ракурс ведения к таблице, а сразу для таблицы запустить генератор ведения, то проблем при ведении не возникает. А если создать ракурс ведения к таблице и к нему сгенерировать диалог, то при сохранении (в процессе ведения ракурса) ДАМП.

На текущий момент у меня созданы 3 таблицы со сгенерированными для них диалогами ведения. По отдельности всё работает нормально. Но вот при объединении их в кластер ракурсов опять возникают траблы. В данном случае вываливается дамп при вызове средства поиска одного из полей отдельного ракурса. Что делать в этом случае не знаю.

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

Да, это не мой случай. Но в связи с этим у меня возникает вопрос: что если ключ родителя вообще не входит в ключ потомка? Грубо говоря у потомка свой "суррогатный" ключ, а ключ родителя у потомка является не первичным, а внешним ключом.

Если ключевое поле не одного из типов CDNST, то всегда будет дамп.
И случайно такого сообщения не было "Записи не могут быть скопированы в запрос", или что-то в этом роде?

Да, такое сообщение есть!!! Что оно означает?

В оригинале сообщение выглядит так: "Никакие отдельные записи не могут быть скопированы в запрос на изменение."
А означает, что при попытке перенести одну запись из таблицы - будет переноситься целиком вся таблица.

Меня интересует вопрос, относится ли данное сообщение к моей проблеме? Похоже что нет.

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