Многие разработчики обновляют доработанные конфигурации путем "сравнения, объединения", что является не всегда верно. До некоторого времени я тоже так делал, пока не произошел случай, после которого пришлось разобраться в произошедшем и перед обновлением всегда готовить точную последовательность действий, а способ "сравнения, объединения" использовать лишь в исключительных случаях.
Пример №1. Некорректное сопоставление таблиц.
В конфигурации есть РегистрСведений1:
Измерения:
Измерение1
Измерение2
Ресурсы:
Ресурс1
Ресурс2
Что делают разработчики конфигурации в новом релизе:
1) переименовывают регистр РегистрСведений1 на УдалитьРегистрСведений1 - будет удален в следующем релизе;
2) создают новый РегистрСведений1:
Измерения:
Измерение1
Измерение3
Ресурсы:
Ресурс3
Ресурс4
3) выпускают релиз.
Теперь, если запустить обновление конфигурации через "Конфигурация->Сравнить, объединить с конфигурацией из файла...", получим следующий результат сравнения:
Старый регистр сопоставился с новым по одинаковым наименованиям - неверное сопоставление. Последствия такого сравнения - потеря данных; факт потери данных может обнаружиться не сразу, не через день, не через два, и более, когда старые архивы баз будут давно удалены и неоткуда будет восстановить информацию.
При выполнении через "Конфигурация->Загрузить конфигурацию из файла" объекты сопоставились верно (РегистрСведений1=УдалитьРегистрСведений1) - это подтверждает, что данный способ сопоставляет объекты по уникальным идентификаторам. Поэтому в описанном случае необходимо использовать именно способ "Загрузить конфигурацию из файла".
В конфигурации есть РегистрСведений1:
Измерения:
Измерение1
Измерение2
Ресурсы:
Ресурс1
Ресурс2
Что делают разработчики конфигурации в новом релизе:
1) переименовывают регистр РегистрСведений1 на УдалитьРегистрСведений1 - будет удален в следующем релизе;
2) создают новый РегистрСведений1:
Измерения:
Измерение1
Измерение3
Ресурсы:
Ресурс3
Ресурс4
3) выпускают релиз.
Теперь, если запустить обновление конфигурации через "Конфигурация->Сравнить, объединить с конфигурацией из файла...", получим следующий результат сравнения:
Старый регистр сопоставился с новым по одинаковым наименованиям - неверное сопоставление. Последствия такого сравнения - потеря данных; факт потери данных может обнаружиться не сразу, не через день, не через два, и более, когда старые архивы баз будут давно удалены и неоткуда будет восстановить информацию.
При выполнении через "Конфигурация->Загрузить конфигурацию из файла" объекты сопоставились верно (РегистрСведений1=УдалитьРегистрСведений1) - это подтверждает, что данный способ сопоставляет объекты по уникальным идентификаторам. Поэтому в описанном случае необходимо использовать именно способ "Загрузить конфигурацию из файла".
Пример №2. Замена типов полей.
В конфигурации есть типовой регистр сведений ДанныеБизнесПроцессов с измерением "БизнесПроцесс", у которого тип "БизнесПроцессСсылка". Это означает, что любой объект "Бизнес-процесс" может быть измерением регистра.
1) В конфигурацию добавили новые бизнес-процессы: БП_Уведомление, БП_СогласованиеПремий, БП_СогласованиеШтрафов.
1) В конфигурацию добавили новые бизнес-процессы: БП_Уведомление, БП_СогласованиеПремий, БП_СогласованиеШтрафов.
2) В регистре ДанныеБизнесПроцессов добавили строки, содержащие ссылки новых бизнес-процессов (П_Уведомление, БП_СогласованиеПремий, БП_СогласованиеШтрафов).
3) В новом релизе типовой конфигурации тип измерения БизнесПроцесс меняется на ОпределяемыйТип, содержащий только типовые бизнес-процессы.
Соответственно, в регистре ДанныеБизнесПроцессов очищаются ссылки нетиповых бизнес-процессов и образуются дубли строк, удаляются данные. При реорганизации информации (реструктуризации) возникает ошибка применения изменений, "Принять" изменения невозможно.
Текст ошибки: "Записи регистра сведений стали неуникальными: ДанныеБизнесПроцессов".
Данная ошибка незаметно и неявно допускается при подготовке обновленной конфигурации на пустой базе, и выявляется такая ошибка уже при установке обновленной конфигурации на копии рабочей базы. Поэтому правку типов приходится выполнять уже по факту выявления.
Данная ошибка незаметно и неявно допускается при подготовке обновленной конфигурации на пустой базе, и выявляется такая ошибка уже при установке обновленной конфигурации на копии рабочей базы. Поэтому правку типов приходится выполнять уже по факту выявления.
Выводы:
1) Если есть возможность обновить конфигурацию через "Конфигурация->Загрузить конфигурацию из файла", то лучше именно так и делать.
2) Обновление способом "Сравнить, объединить..." имеет риск потери информации, использовать следует только после невозможности использования способа "Загрузить конфигурацию из файла" и только при проверке всех объектов и реквизитов. Если в ходе проверки объектов и реквизитов новой конфигурации обнаруживается описанная ситуация с одинаковыми наименованиями, то варианты обновления следующие:
2.1) Ручная отмена сопоставления в окне сравнения, повторное обновление списка сравнения, ручное сопоставление; если эти действия по каким-то причинам невозможны, есть следующие варианты обновления в (2.2) и (2.3).
2.2) подготовка файлов поставки обновления;
2.3) "Конфигурация->Поддержка->Обновить конфигурацию",
2.3.1) выбрать типовой файл, в этом случае объекты сопоставляются верно и они переименовываются в соответствии с новым релизом, нетиповой код и элементы форм можно не учитывать, главное учесть объекты хранения данных.
2.3.2) теперь можно использовать "Конфигурация->Сравнить, объединить с конфигурацией из файла...", т.к. объекты уже переименованы.
3) Всегда нужно готовить check-лист, точную последовательность действий по обновлению рабочей базы. Меньше шансов запутаться у сотрудника, выполняющего обновление рабочей базы, меньше риск ошибки. Также этот лист можно впоследствии проверять, корректировать, дополнять.
Комментариев нет:
Отправить комментарий