[SergeK]

Цитата:

Сообщение от kashperuk

Дай прямую ссылку на конкретный ответ - и думаю, добавят

Да, не вопрос!

Цитата:

Сообщение от EVGL

Сам поставил опыт: вы не поверите, но поля в индексе, который выбран как PrimaryIndex на таблице, действительно становятся членами первичного ключа в SQL!
Relations не при чем, а то, что написано в документации, относится к первичному ключу в понимании Аксапты, т.е. к полю, которое можно переименовывать. Именно для глобального переименования кодов справочников и нужны self-relatations.

Цитата:

Сообщение от EVGL

Запуск BestPractice дает ответ на этот вопрос. Self-relation нужны для переименования первичных ключей.
Если расширенный тип не имеет такой ссылки, то BestPractice выдает соответствущее предупреждение и ждет, что ссылка будет создана на самой таблице. Однако в ряде таблиц (RAssetMoveHist, скорее всего, в их числе) первичного ключа либо нет, либо он состоит из нескольких полей. Тут попытка создать Self-relation ни к чему не приводит: BestPractice продолжает ошибочно выдавать все то же предупреждение.

Есть и еще одна причина: в ряде случаев программист хочет, чтобы при вызове формы создалась динамическая ссылка с источником данных вызываеющего объекта. Пример: вызов проводок по ГК из плана счетов. А если вызывающая и вызываемая таблицы одинаковые? Если таблицу рабочих центров вызываем из формы рабочих центров и хотим видеть, как содержимое второй формы фильтруется по номеру из первой? Автоматически наложить правильный DynaLink на таблицу (особенно с первичным ключом из двух и более полей) в таком случае помогает Self-relation.

Цитата:

Сообщение от EVGL

Не в первый раз поднимался этот вопрос. Эта relation сделана для того, чтобы Best Practices не ругался. Вот и все. А Best Practices ругается тогда, когда переименование первичного ключа невозможно, т.е. нет уникального индекса. Поэксперементируйте, и все станет понятно.