Господа, может ли кто объяснить отличия между "загрузить конфигурацию" и "сравнить/объеденить конфигурацию" . Прочитав не одну статью выводов так сделать не получилось. Главный вопрос если загрузить конфигурацию влияет ли это в отличие от "сравнить/объеденить конфигурацию" на индексирование таблиц базы данных и если да то каким образом.
---
Главное отличие из неочевидных - при сравнении/объединении сопоставление элементов метаданных производится по их именам, а при загрузке - по внутренним идентификаторам метаданных.
Как следствие - если загружаемая конфа копия исходной, в которой элемент переименовали, то при загрузке он тоже переименуется в целевой конфе, а структурных изменений не будет (по идее). А вот через сравнение/объединение будет предложено удаление старого и добавление нового элемента.
Как второе следствие - если две разные базы были созданы из одного родителя, но потом обнолялись якобы одинаково, но через сравнение/объединение, то их строгая идентичность не гарантирована, так как из-за разного порядка обновлений элементы метаданных с одинаковыми именами могли получить разные внутренние идентификаторы. И, например, попытка свести их потом в РИБ, который подразумевает строгую идентичность конфигураций, может внезапно оказаться не такой простой.
---
а в чем собственно проблема ? Если надо только внести изменения в основную конфу, то всегда использую сравнить/объеденить. Если надо еще одновременно и конфигурацию поставщика обновить, загрузить
---
загрузить предполагает что исходная конфигурация будет заменена загружаемой со всеми вытекающими. Сравнить/объединить сначала сравнит объекты, затем объединит по неким правилам с исходной. Что бы понять как все это работает можете взять и на копии какой нибудь не нужной базы поиграть данними операциями. Помните что для успешной замены нужно снять с поддержки все объекты конфигурации.
---
Главное отличие из неочевидных - при сравнении/объединении сопоставление элементов метаданных производится по их именам, а при загрузке - по внутренним идентификаторам метаданных.
Как следствие - если загружаемая конфа копия исходной, в которой элемент переименовали, то при загрузке он тоже переименуется в целевой конфе, а структурных изменений не будет (по идее). А вот через сравнение/объединение будет предложено удаление старого и добавление нового элемента.
Как второе следствие - если две разные базы были созданы из одного родителя, но потом обнолялись якобы одинаково, но через сравнение/объединение, то их строгая идентичность не гарантирована, так как из-за разного порядка обновлений элементы метаданных с одинаковыми именами могли получить разные внутренние идентификаторы. И, например, попытка свести их потом в РИБ, который подразумевает строгую идентичность конфигураций, может внезапно оказаться не такой простой.
---
В конфигураторе есть удобный режим сравнения конфигураций, в котором есть специальная галка режима сравнения.
---
Наверное, нужно уточнить в контексте "основной" конфигурации и "конфигурации базы данных (БД)". Все знают, что сначала происходит изменение основной конфигурации, а потом происходит ее "накатывание" на конфигурацию БД.
Поэтому правильнее будет сказать так: при накатывании основной конфигурации на конфигурацию БД их сопоставление ВСЕГДА происходит по внутренним идентификаторам. Просто "загрузить конфигурацию" полностью заменяет основную конфигурацию и остается только этап накатывания основной конфигурации на конфигурацию БД. Поэтому никаких двусмысленностей быть уже не может. Сопоставление только по внутренним идентификаторам. Новые элементы зальются с теми идентификаторами, которые были в загружаемой конфигурации.
А режим объединения/сравнения позволяет "сконструировать" основную конфигурацию из каких угодно источников, опираясь на сравнение по именам. При этом новым элементам метаданных будут присвоены КАКИЕ-ТО ОЧЕРЕДНЫЕ внутренние идентификаторы в КОНТЕКСТЕ ОБНОВЛЯЕМОЙ КОНФИГУРАЦИИ. НЕ ОБЯЗАТЕЛЬНО ТЕ, ЧТО БЫЛИ В ИСТОЧНИКЕ (просто могут совпадать, если базы всегда обновлялись единообразно). А потом уже получившийся результат будет накатываться на конфигурацию БД, сопоставляя по внутренним идентификаторам метаданных.
---
получается, если я удалю какой-нибудь реквизит и тут же его создам с абсолютно такими же свойствами, при обновлении конфигурации БД данные этого реквизита затрутся, т.к. идентификаторы будут различны?
---
при загрузке идет сравнение по именам вроде
---
извините, имел ввиду непосредственное редактирование основной конфигурации
---
удалю какой-нибудь реквизит и тут же его создам с абсолютно такими же свойствами,
таки да, это будет новый реквизит, данные старого затрутся.
---
Как уже сказали - да, затрутся (физически в БД из таблицы объекта будет удалена колонка старого реквизита и будет создана новая колонка с другим названием). Если в основной конфигурации удалили реквизит случайно, то нужно сделать "Вернуться к конфигурации БД". Тогда основная конфигурация перезальется из конфигурации БД.
---
А как все это может влиять на индексирование таблиц базы данных
---
зачем Вам это знать?
---
После обновления конфигурации через "Загрузить конфигурацию" в одном из документов появилась не объяснимая ошибка которая пропала после Индексирования. Теперь появился спор - могло и главное как загрузить конфигурацию могло изменить индексацию таблиц базы данных
---
Непонятно, что у вас произошло. Для восстановления событий информации маловато. Но если в самом деле слетел какой-то индекс в результате сбоя при обновлении, то прямой связи с режимом обновления я не вижу. Этот этап общий для обоих режимов.
А чтобы контролировать, что в самом деле произойдет после заливки конфы через "загрузку" - рекомендую всегда перед накатыванием на БД делать сравнение основной конфигурации и конфигурации БД через "Сравнение конфигураций" со снятой галкой "Устанавливать соответствия по именам объекта". В этом режиме сравнение происходит быстро и показывает, какие именно изменения будут внесены в конфигурацию БД.
---
Т.е что бы понять все это "Одна бабка сказала" или действительно Загрузить конфигурацию влияет на индексирование таблиц базы данных. Просто если есть влияние хотелось бы узнать какое