Сразу оговорюсь, что проблема эта возникает крайне редко, но как показал мой опыт, она может возникнуть совсем неожиданно. Итак, в конфигурацию я должен был добавить новый справочник, и, самое странное, должен был поставить ему в подчинение уже существующий справочник, причем активно использующийся.
Если делать это штатными средствами, 1с при сохранении конфигурации выдает сообщение, что справочник такой-то имеет записи и не может быть подчинен.
Я не буду вас томить описанием долгих поисков истины, хотя, может быть, это самое интересное в работе программиста.
Итак, готовый рецепт.
Подчиненный справочник отличается от обычного наличием поля PARENTEXT, в котором хранится ссылка на владельца. Поскольку 1с сама не в состоянии создать это поле, мы должны ему помочь.
Предположим, что нашему справочнику соответствует таблица SC1234. Находим эту таблицу и добавляем поле PARENTEXT, установив тип char(9). Попутное замечание: все поля в одиэсовских таблицах имеют дополнительный параметр NOT NULL. Поскольку мы не можем в момент добавления поля проставить всех владельцев, то мы должны сбросить этот параметр, чтобы поле могло добавиться в таблицу. Скорее всего из-за этого 1с самостоятельно не может установить подчинение.
Если теперь зайти в режим предприятия, то 1с выдаст сообщение, что нарушена структура таблицы SC1234. Так и должно быть. Словарь данных о новом поле еще ничего не знает. Зайдем в конфигуратор, установим подчинение и сохраним конфигурацию. Вуаля! На этот раз подчинение проходит без каких либо сложностей.
PS. Должен сделать важное дополнение. Надеюсь, еще никто не воспользовался мои методом. Спасибо товарищу Ёпрст за сомнения и справедливые замечания по поводу отсутствия всякого упоминания о его методе решения данной проблемы. Вот он:
1.Делаешь выгрузку данных.
2.Удаляешь элементы справочника, который будешь переподчинять или можно просто удалить соответствующую таблицу DBF или SQL.
3.Переподчиняешь справочник.
4.Старый МД-ник в выгрузке заменяешь новым.
5.Делаешь загрузку данных.
6.Назначаешь владельцев.
Этот метод абсолютно надежен, т.к. при загрузке данных текущие таблицы уничтожаются и создаются новые. Поэтому, если позволяет размер базы, пользуемся этим способом.
При реализации моего метода в рабочей базе я столкнулся с тем, что мой справочник, который я хотел подчинить, очистился. Не могу точно сказать, почему в тестовой базе метод сработал: там я одновременно пытался редактировать файл метаданных и словарь данных сторонними программами. Все это предстоит еще раз исследовать.
Но данный казус хоть и неприятен, не настолько страшен, чтобы испортить жизнь. Мы, все-таки программисты, а не домохозяйки. :) Берем бэкап, разворачиваем и делаем импорт таблицы (в нашем случае sc1234) из бэкапа в рабочую базу. Все.
Приношу свои извинения за публикацию непроверенного метода.
