Обновление Бухгалтерии 3.0, в состоянии расхождения объектов по внутренним идентификаторам

Программирование - Практика программирования

Обратился клиент с измененной Бухгалтерией 3.0. При сравнении с базой поставщика, через Поддержка-Настройка поддержки,  дает значительный разбег конфигураций - примерно 40% измененных объектов + 20% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".  

База Бухгалтерии 3.0 - клиенту известно, что изменения есть, но их не должно быть много, касаются нумерации некоторых документов.

При сравнении с базой поставщика, через Поддержка-Настройка поддержки,  дает значительный разбег конфигураций - примерно 40% измененных объектов + 20% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".  

Однако, при сравнении с файлом (конфигурация поставщика выгружена в файл) - фактических различий в конфигурациях 1-2%.

Видимо в какой-то момент обновляли путем сравнение-объединение с файлом конфигурации поставщика -  как в свое время делалось в 7.7 - и все новые объекты получили свои новые внутренние идентификаторы и не соотносятся с аналогичными в типовой.

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

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

В данном примере повезло - кривое обновление базы не затронуло серьёзных объектов, содержащих данные - в основном макеты, формы, отчеты, обработки, модули . Но сначала это было не явно - присутствовали и регистры, и константы, и документы.  

Опишу этапы, по которым действовала, может, кому поможет, кого-то наведет на мысль . 

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

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

В моем случае несказанно повезло: 3 регистра,  2 константы и 1 вид документа оказались не использованы - данных по ним не было и сохранять не нужно было - с ними я поступила аналогично 1 пункту.

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

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

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

См. также

Лучшие комментарии
5. max maxx (motorkuzbassa.it) 60 05.10.17 14:44 Сейчас в теме
все намного проще. ..
1.Снять с поддержки и "сравнить объединить.."с постановкой на поддержку с текущим .cf поставщика (который можно тут же и выгрузить), вернет всем объектам родные уиды. т.к. сравнение идет по именам объектов. а все дописи соттветственно в лице реквизитов новых останутся.
2. сравнить с измененной конфой на предмет изменений модулей и форм...радоваться..
gigapevt; user_2010; kiruha; Dmitri93; rpgshnik; VladimirL; olgerd666; klinval; +8 1 Ответить
Остальные комментарии
1. Вячеслав (slawa) 24 05.10.17 13:00 Сейчас в теме
Видимо в какой-то момент обновляли путем сравнение-объединение с файлом конфигурации поставщика - как в свое время делалось в 7.7

Сравнение-объединение в 8-ке переносит реквизиты вместе с их внутренними идентификаторами.
Скорее всего объекты, из новой конфигурации поставщика, переносили с помощью Ctrl+C - Ctrl-V
kiruha; klinval; +2 Ответить
3. Uladzimir - (nvv1970) 05.10.17 14:23 Сейчас в теме
(1)
Сравнение-объединение в 8-ке переносит реквизиты вместе с их внутренними идентификаторами.
Откуда информация? 1с говорит об обратном.
Если например в хранилище добавить новый объект и потом сравнить/объединить цф с рабочей, то новый объект будет с новым, отличающимся от хранилища, идентификатором. Так же новым будет имя таблицы в СУБД, но не об этом речь.
Соответственно следующее сравнение цф будет более долгим, т.к. по ГУИДу объект не будет найден и будет произведен поиск по ИМЕНИ для сопоставления.
Как-то так.
А вот при полной замене цф все идентификаторы будут заменены на те, что в файле цф.
9. Вячеслав (slawa) 24 06.10.17 01:36 Сейчас в теме
(3)
Откуда информация? 1с говорит об обратном.

Из личного опыта.

Создайте базу с одним справочником, выгрузите ЦФ
Создайте еще одну базу с одним справочником (лучше с другим именем, чем в первой), сравните и объедините в нее ЦФ от первой базы
Разберите конфигурации на файлы и посмотрите там ГУИДы справочников.

Не путайте с наименованием таблиц и полей.
14. Uladzimir - (nvv1970) 08.10.17 21:51 Сейчас в теме
(9) Есть на итс вот такая древняя статья.
В ней упоминание про древние релизы платформы. Но по существу скорости сравнения конфигураций воз и ныне там. Поэтому я склонен верить статье.

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

Однако я так же вижу, что при групповой разработке, если рабочая (продакшн) база не подключена к хранилищу (обновляется ч/з сравнение/объединение), то после первого же добавленного нового объекта в хранилище сравнение начинает подтупливать. Чем больше новых объектов было добавлено после создания хранилища - тем больше тормозит сравнение. Из 10-20 сек сравнение может превратиться в 10-30 минут.
Есть еще интересная особенность... Если развернуть в тестовую базу бэкап обновленной рабочей базы и подключить ее к хранилищу (дефакто конфигурации будут в такой момент одинаковые), то конфигурация бэкапа заменится за конфигурацию хранилища. При последующем обновлении пройдет реструктуризация половины базы несмотря на фактическое отсутствие изменений. Никогда не расследовал что именно реструктуризируется, но предположу, что это именно новые объекты (созданные в процессе жизни хранилища). И еще замечу, что если рабочая база подключена к хранилищу разработки и из него обновляется через получение изменений, то такого эффекта нет.
Это тоже опыт. И даже не личный, а коллективный.
Возможно он не противоречит тому что мы видим в xml, а всего лишь говорит о том, что мы видим не все.
15. Валерий К (klinval) 210 10.10.17 11:34 Сейчас в теме
(9)
Создайте базу с одним справочником, выгрузите ЦФ
Создайте еще одну базу с одним справочником (лучше с другим именем, чем в первой), сравните и объедините в нее ЦФ от первой базы
Разберите конфигурации на файлы и посмотрите там ГУИДы справочников.

Проверил, действительно гуиды равны. Но ещё поддержу (14): тоже работаем через хранилище и по ряду косвенных признаков, описанных в комментарии, видно что внутренние идентификаторы не равны. Плюс есть не древняя статья: Общие правила обмена объектами метаданных между конфигурациями. Там сказано:
Механизм: Объединение конфигураций.
Способ сопоставления: Сопоставление по имени. При отсутствии соответствия по имени – сопоставление по внутреннему идентификатору. Возможна ручная установка соответствия.
Поведение идентификатора при перемещении объекта: При копировании нового объекта изменяется. При объединении двух объектов, между которыми обнаружено соответствие, не изменяется.
...
Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:

1. Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
2. Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
3. Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.


Правда есть ещё справка по 8.3.10:
По умолчанию при объединении конфигурации объекты, отсутствующие в основной конфигурации, добавляются в нее с теми идентификаторами, которые существуют у них в загружаемой конфигурации.

Установка флажка Режим копирования объектов... позволяет выполнять добавление новых объектов по правилам, существовавшим в предыдущих версиях платформы: при добавлении объектов, отсутствующих в основной конфигурации, для них всегда генерируются новые идентификаторы.

При нажатии кнопки ОК производится повторное сравнение с учетом выбранной настройки.


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


Итого:
В ИТС информация разнится. Возможно раньше было создание объектов с новыми идентификаторами, а в какой-то версии начали создаваться беря идентификаторы из файла. Но даже с одинаковыми идентификаторами при подключении к хранилищу происходит реструктуризация.
17. Вячеслав (slawa) 24 12.10.17 01:56 Сейчас в теме
(15)
тоже работаем через хранилище и по ряду косвенных признаков, описанных в комментарии, видно что внутренние идентификаторы не равны.


Зачем гадать?
Ответил в (16)
18. Валерий К (klinval) 210 12.10.17 10:16 Сейчас в теме
(17)
Все базы разобрал - ГУИДы везде одинаковые

Ранее я написал:
Я посмотрел старые созданные объекты - там идентификаторы одинаковые.

Не совсем подробно описал: это я сверял самый первый новый объект, созданный в хранилище, с рабочей базой. В рабочую добавляем через "Сравнить/объединить". Гуид оказался одинаковым. Так что я подтверждаю, что они равны...

Но, это не отменяет того факта, что при подключении к хранилищу свежей базы происходит массовая реструктуризация (хотя конфигурации равны). Я не знаю чем это объяснить, т.к. если нет изменений, то зачем реструктуризировать данные? Добавилась какая-то служебная информация для конфигурации (чтобы функционировать в хранилище), но данные то тут при чём? При обновлении и то меньше реструктуризируется, чем при подключении к хранилищу!

Плюс в ИТС в двух местах прямо написано, что при сравнить/объединить гуиды не должны быть равны, а в одном косвенно указывают на то, что должны копироваться.
16. Вячеслав (slawa) 24 12.10.17 01:54 Сейчас в теме
(3)
Если например в хранилище добавить новый объект и потом сравнить/объединить цф с рабочей, то новый объект будет с новым, отличающимся от хранилища, идентификатором.


Проверил:

Сделал базу Рабочая с одним справочником
Скопировал .1сд файл Рабочей в две базы Хран1 и Хран2
Из Хран1 создал хранилище конфигурации
Подключил Хран2 к хранилищу.
В Хран2 добавил новый справочник. Закоммител изменения.
Получил изменения в Хран1
Выгрузил ЦФ из Хран1
СравнилИОбъеденил ЦФ с Рабочей базой

Все базы разобрал - ГУИДы везде одинаковые
2. Валерий К (klinval) 210 05.10.17 14:09 Сейчас в теме
1. Справка - О программе - Версия конфигурации
2. Конфигурация - Поддержка - Настройка поддержки - Версия
Эти две версии совпадали до ваших действий?

Пробовали играться с настройкой "Установить соответствие объектов" при сравнении/объединении с конфигурацией поставщика? Может это будет правильным решением вашей проблемы?
4. Валерий К (klinval) 210 05.10.17 14:42 Сейчас в теме
готовим обработку по переносу данных из него в типовой объект

В старой базе объект называется так-же. Через типовую 1С-овскую загрузку/выгрузку в xml просто переносим из старой базы все данные.
5. max maxx (motorkuzbassa.it) 60 05.10.17 14:44 Сейчас в теме
все намного проще. ..
1.Снять с поддержки и "сравнить объединить.."с постановкой на поддержку с текущим .cf поставщика (который можно тут же и выгрузить), вернет всем объектам родные уиды. т.к. сравнение идет по именам объектов. а все дописи соттветственно в лице реквизитов новых останутся.
2. сравнить с измененной конфой на предмет изменений модулей и форм...радоваться..
gigapevt; user_2010; kiruha; Dmitri93; rpgshnik; VladimirL; olgerd666; klinval; +8 1 Ответить
6. Валерий К (klinval) 210 05.10.17 15:31 Сейчас в теме
Сейчас провёл эксперимент:
Типовая БП КОРП. Создал копированием второй справочник "Банки". Перевёл все ссылки/подписки на него. Первоначальный "Банки" снял с поддержки и удалил. Убедился что сравнение объединение мой "Банки" с типовым "Банки" не соотносит.
Снял базу с поддержки. Сделал "Сравнить/объединить" с предварительно выгруженным Cf-ником типовой. Поставил на поддержку. У "Банки" появился "замок". Данные из него не пропали и теперь сравнение с типовой через поддержку не видит в нём различий.

Поэтому поддерживаю (5) комментарий - на практике попробовал: правильный способ описан, лучше чем в статье!
7. Владимир Литвиненко (VladimirL) 584 05.10.17 19:57 Сейчас в теме
(5)
все намного проще. ..
1.Снять с поддержки и "сравнить объединить.."с постановкой на поддержку с текущим .cf поставщика (который можно тут же и выгрузить), вернет всем объектам родные уиды. т.к. сравнение идет по именам объектов. а все дописи соттветственно в лице реквизитов новых останутся.
2. сравнить с измененной конфой на предмет изменений модулей и форм...радоваться..


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

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

Перед обновлением на новый релиз достаточно поставить на поддержку одну из баз через сравнение-объединение с CF-файлом текущего релиза. После чего можно переходить на новый релиз через механизм поддержки.

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

Также этот способ имеет смысл применять только если в компании принят стандарт наименования добавленных в конфигурацию новых объектов. Например их префиксация или постфиксация. Ведь при снятии с поддержки теряется визуальная идентификация типовых объектов.
8. Юлия Орлова (julorl) 8 05.10.17 22:44 Сейчас в теме
(5)
В первый раз столкнулась с такой ситуацией, сравнение измененной и типовой резало глаз, список изменений уходил в даль.
В помощь не нагуглила ничего ценного.
Как я вышла из ситуации описала в статье - если есть лучший способ - прекрасно, в другой раз конечно его использую.
Спасибо.
10. max maxx (motorkuzbassa.it) 60 06.10.17 08:57 Сейчас в теме
(8) Спасибо, закрыли пробел для будущих поколений...)... сделал в помощь..

Быстрый способ сохранить свое бесценное время... Первопричины: При сравнении с базой поставщика, через Поддержка-Настройка поддержки, дает значительный разбег конфигураций - примерно 40(100500)% измененных объектов + 20(100500)% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".
Рецепты:

Основной:

1.Снять с поддержки и "сравнить объединить.."с постановкой на поддержку..." с текущим .cf поставщика (который можно тут же и выгрузить. Важно: при расхождении номеров версий конфигураций основной и поставщика, конечно нужно найти/использовать релиз поставщика, именно с номером основной конфигурации), вернет всем объектам родные уиды и замки. т.к. сравнение идет по именам объектов. а все дописи соответственно в лице реквизитов новых останутся.
2. сравнить с измененной конфигурацией(которую можно тут же и выгрузить) на предмет изменений модулей и форм, привести в соответствие, необходимые изменения...радоваться..
11. Юлия Орлова (julorl) 8 06.10.17 12:43 Сейчас в теме
(10)
но насчет "сравнение идет по именам объектов" часто в версиях имена и объектов и общих модулей и форм меняются.
12. max maxx (motorkuzbassa.it) 60 06.10.17 13:49 Сейчас в теме
(11)так мы же текущую конф.основную ставим на поддержку на текущую.поставщика. где ж там будут такие изыски...а не сразу летим на самый крайний..)..рекомендую именно с этого начать..), т.е. релизы ставим номер в номер..
Оставьте свое сообщение