gifts2017

1c v 7.7. Установка владельца для справочника, имеющего записи.

Опубликовал Майкопчанин (Майкопчанин) в раздел Программирование - Практика программирования

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

 

 

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

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

 Я не буду вас томить описанием долгих поисков истины, хотя, может быть, это самое интересное в работе программиста.

 Итак, готовый рецепт.

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

 Предположим, что нашему справочнику соответствует таблица SC1234. Находим эту таблицу и добавляем поле PARENTEXT, установив тип char(9). Попутное замечание: все поля в одиэсовских таблицах имеют дополнительный параметр NOT NULL. Поскольку мы не можем в момент добавления поля проставить всех владельцев, то мы должны сбросить этот параметр, чтобы поле могло добавиться в таблицу. Скорее всего из-за этого 1с самостоятельно не может установить подчинение.

 Если теперь зайти в режим предприятия, то 1с выдаст сообщение, что нарушена структура таблицы SC1234. Так и должно быть. Словарь данных о новом поле еще ничего не знает. Зайдем в конфигуратор, установим подчинение и сохраним конфигурацию. Вуаля! На этот раз подчинение проходит без каких либо сложностей.

PS. Должен сделать важное дополнение. Надеюсь, еще никто не воспользовался мои методом. Спасибо товарищу Ёпрст за сомнения и справедливые замечания по поводу отсутствия всякого упоминания о его методе решения данной проблемы. Вот он:

1.Делаешь выгрузку данных.
2.Удаляешь элементы справочника, который будешь переподчинять или можно просто удалить соответствующую таблицу DBF или SQL.
3.Переподчиняешь справочник.
4.Старый МД-ник в выгрузке заменяешь новым.
5.Делаешь загрузку данных.
6.Назначаешь владельцев.

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

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

Но данный казус хоть и неприятен, не настолько страшен, чтобы испортить жизнь. Мы, все-таки программисты, а не домохозяйки. :) Берем бэкап, разворачиваем и делаем импорт таблицы (в нашем случае sc1234) из бэкапа в рабочую базу. Все.

Приношу свои извинения за публикацию непроверенного метода.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Илья (gucci76) 28.04.10 11:37
Цитата:"в конфигурацию я должен был добавить новый справочник, и, самое странное, должен был поставить ему в подчинение уже существующий справочник"
Так конфигурация становится нетиповой.
Я бы сделал без подчинения, а с отбором по реквизиту. В новом справочник, сделал реквизит с типом значения "ОлдСправочник" и отбор по этому реквизиту. При поиске подчиненных элементов модуль увеличился бы на несколько строк, но конфа осталось бы типовой.
ИМХО
2. Майкопчанин (Майкопчанин) 28.04.10 11:43
(1) Во-первых конфигурация у меня совсем не типовая, а во-вторых, нужно было непременно установить подчинение.
4. Епрст (Ёпрст) 28.04.10 12:48
А так, способ - не очень.. важна еще последовательность полей в табличке - ибо индекс строится потом..
5. Майкопчанин (Майкопчанин) 28.04.10 12:56
(3) Читал, попадался мне этот метод. Не устроил. База у меня оченно большая. На загрузку данных ушел бы целый день.
(4) Ну и новое поле никто не заставляет вставлять в конец. Можно и нужно вставлять после DESCR
6. Епрст (Ёпрст) 28.04.10 13:07
(5) ну дык, неплохо указать на это в сабже.
:)
7. Аркадий Кучер (Abadonna) 29.04.10 08:20
(3)
Сто пудов метод автора быстрее в разы. Из-за одного справочника делать выгрузку-загрузку - :cry:
(0) А по (6) я бы тебе советовал добавить в описание. Эх, молодежь, не писали в советское время вы описания к изобретениям :D
отличающаяся тем, что...
8. Алексей (ACE$) 30.04.10 09:41
(0) в свое время я не стал этим заморачиваться, и сделал по (1), хотя надобность такая была
9. Евгений Долиновский (Dolly_EV) 05.05.10 04:06
Еще бы к сабжу добавить обработочку, которая потом владельцев назначает..., а так зачОт ;)
10. Рожков Сергей Васильевич (SVR27) 05.05.10 09:22
А еще можно объединить способы автора и ёпрст: вместо выгрузки данных просто перенести файл справочника из базы во временную папку, внести изменения в конфигурацию, а потом открыть вновь созданную конфигуратором таблицу справочника и импортировать в него данные из перенесенного файла.
11. Майкопчанин (Майкопчанин) 05.05.10 09:37
(6)(7) В связи с вновь открывшимися подробностями, сделал дополнение к публикации. Спасибо за замечания.
(9) Такая обработка не то чтобы проста, она примитивна. А ее реализация зависит от структуры базы. Так что нет смысла выкладывать программу, которая никому не пригодится.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа