1с сравнить объединить конфигурацию с хранилищем
Особенности сравнения и объединения конфигураций в режиме обновления
Для сопоставления объектов при объединении конфигурации в 1С:Предприятии 8 используются свойство "Имя" объекта метаданных и его внутренний идентификатор. Однако в различных вариантах сравнения алгоритм сопоставления объектов разный. Прежде чем подробно описать различные варианты, сначала опишем правила изменения внутреннего идентификатора. Идентификатор в пределах одной конфигурации никогда не изменяется. Идентификатор не изменяется при выгрузке конфигурации в cf или dt файлы (включая файлы поставки cf и обновления cfu ). Идентификатор не изменяется при использовании механизма групповой разработки (в процессе перемещений между конфигурацией и хранилищем). Идентификатор всегда изменяется при копировании объекта, в том числе в процессе объединения конфигураций. Поясним на примере. Создаем новую конфигурацию. Выполняем команду " Конфигурация - Сравнить, объединить с конфигурацией из файла. ". Программа обнаружит что текущая конфигурация пустая и предложит выполнить полную загрузку (аналогично команде " Конфигурация - Загрузить конфигурацию из файла "). Если согласится на предложенный вариант, то в результате все объекты сохранят свои идентификаторы. Если же отказаться и выполнить обычное объединение, то все объекты идентификаторы поменяют, хотя логически получатся две одинаковые конфигурации.
Теперь рассмотрим алгоритмы сопоставления объектов. Существуют три варианта.
- Сравнение произвольных конфигураций. Выполняется сопоставление по имени объекта. Если для каких-то объектов пару найти не удалось, выполняется сопоставление по идентификатору.
- Сравнение родственных конфигураций. Имеются ввиду конфигурации, про которые можно точно утверждать, что они являются различными версиями одной и той же конфигурации (примеры - сравнение основной конфигурации с конфигурацией базы данных или с конфигурацией хранилища). Выполняется сопоставление только по идентификатору объекта. Имя объекта не используется.
- Сравнение с конфигурацией поставщика. Выполняется сопоставление по идентификаторам, но при этом идентификаторы не обязательно должны быть одинаковы.
Третий вариант мы рассмотрим отдельно, но сначала некоторые уточнения про первые два. Сравнение конфигураций можно вызвать из различных режимов. Например, используя команды " Конфигурация - Сравнить, объединить с конфигурацией из файла. ", " Конфигурация - Конфигурация базы данных - Сравнить, объединить с конфигурацией базы данных ", из диалога настройки поддержки, и так далее. Во всех этих случаях вариант сопоставления выбирается автоматически. Есть также команда универсального сравнения конфигураций "Конфигурация - Сравнить конфигурации. ". Где можно выбрать любую пару (например конфигурацию базы данных с некоторой версией из хранилища конфигураций). В случае если будет указана пара конфигураций, связь между которыми известна, вариант сопоставления так же будет выбран автоматически. В противном случае, будет доступен флажок "Устанавливать соответствия по именам объектов", который позволяет в явном виде выбрать один из двух алгоритмов.
Уточнение: автоматический выбор будет сделан не только при условии выбора известной пары, но и при правильном порядке, когда первой указывается основная конфигурация. Этим можно воспользоваться для того, чтобы изменить алгоритм сопоставления для известной пары конфигураций, достаточно их поменять местами.
Теперь рассмотрим вариант сравнения с конфигурацией поставщика. Его особенность связана с наличием двух вариантов поддержки - с включенной возможностью изменений и без. Во втором случае обновление выполняется путем загрузки новой версии конфигурации поставщика, то есть, как было описано выше, идентификаторы объектов при этом не изменяются. В первом случае используется управляемое объединение конфигураций, и при этом новые объекты получают новые идентификаторы. Вместе с тем, сопоставлять объекты по именам в этом случае нельзя, поскольку изменение пользователем имени не должно приводить к потере связи с объектом поставщика. В связи с этим используется следующая техника. Для каждого объекта поставщика запоминается пара идентификаторов объектов (в конфигурации поставщика и в конфигурации на поддержке). И сопоставление выполняется только по этим парам. Для обеспечения логической целостности поддержки конфигурации единожды созданная пара никогда не изменятся. Если в новой версии поставщика появился новый объект, то пользователь при обновлении может просто его скопировать, а может сопоставить с каким-то своим объектом. Но в дальнейшем эту связь изменить будет нельзя.
Влияние сопоставления объектов на скорость сравнения конфигураций
Сравнение больших конфигураций - процедура достаточно длительная, особенно в режиме обновления конфигурации поставщика, когда производится три сравнения (старой и новой конфигурации поставщика, и конфигурации пользователя с каждой из них). Общее правило можно сформулировать так - сравнение выполняется в оптимизированном режиме (намного быстрее) в случае соблюдения двух условий:
- Среди сопоставленных объектов нет пар с различными идентификаторами.
- Среди несопоставленных объектов нет возможных пар с одинаковыми идентификаторами.
На основе этих правил можно объяснить разницу в скорости сравнения при обновлении конфигураций. Версии конфигурации поставщика всегда сравниваются максимально быстро, поскольку они получаются из одной и той же конфигурации путем создания файлов поставки и - или обновления и, как было указано выше, идентификаторы объектов остаются неизменными. Скорость сравнения конфигурации пользователя зависит от истории изменений в версиях конфигурации поставщика. После того как пользователь включил возможность изменений, сравнение происходит быстро, поскольку идентификаторы всех сопоставленных объектов одинаковы. Но как только в каком-либо из обновлений поставщик добавит хотя бы один новый объект, после выполнения обновления этот объект получит новый идентификатор, и все последующие сравнения пользовательской конфигурации с конфигурацией поставщика будут выполняться заметно медленнее.
Замечания по методике использования механизма
Часто у специалистов выполняющих внедрение возникает вопрос, как правильно ставить конфигурацию на поддержку: включать возможность изменения в дистрибутивном варианте конфигурации поставщика или свою собственную конфигурацию объединить с этим дистрибутивом с одновременной постановкой на поддержку. Принципиальной разницы нет. Логически результат будет одинаковый, что же касается скорости сравнения при последующих обновлениях, то в первом случае она будет намного выше, но лишь до того момента как поставщик в новой версии добавит хотя бы один новый объект, что, весьма вероятно, произойдет уже в следующей версии. После чего уже никаких отличий в скорости сравнения не будет.
Удаление объектов поставщика
Рассмотрим варианты удаления объекта поставщика.
Удаление пользователем
Для того чтобы удалить объект поставщика, пользователь должен сначала снять с поддержки его и всех ему подчиненных. При последующих обновлениях этот объект не будет помечаться на объединение.
Удаление поставщиком
Начиная с релиза платформы 8.0.7, при выполнении любого объединения конфигураций существует возможность удаления объектов основной конфигурации. По умолчанию эта возможность включена только в режиме обновления конфигурации поставщика. Для включения ее в других режимах следует установить флажок " Разрешить удаление объектов основной конфигурации " в диалоге настройки сравнения и объединения конфигураций.
Расстановка пометок удаления объектов поставщика по умолчанию производится по следующим правилам. Если пользователь изменял объект поставщика по сравнению с предыдущей версией конфигурации поставщика, то объект по умолчанию не помечается на удаление, если объект идентичен объекту поставщика предыдущей версии, то он на удаление помечается. Если объект был помечен на удаление (автоматически или вручную), то при нажатии кнопки "Выполнить" происходит контроль ссылочной целостности. При обнаружении неразрешимых ссылок на удаляемый объект, будет выдано окно показа таких ссылок но, в отличии от неразрешимых ссылок, образующихся в результате отказа от копирования какого либо объекта конфигурации поставщика (или любой другой конфигурации, участвующей в объединении), возможности продолжить объединение (и удаление объекта) в этом случае нет.
Туплю. Поможите, плиз.
Имеется сохраненная в файл конфа.
Имеется тестовая конфа подключенная к хранилищу основной конфы.
Как накатить данные из файла в хранилище сравнением/объединением?
В меню >>"Конфигурация">>"Хранилище конфигурации" только сравнение.
В меню >>"Конфигурация">>"Сравнить/объединить конфигурации" пишецца, что редактирование объекта запрещено.
захватить те объекты, что нужно объединить (если удалить или добавить объекты, тогда конфигурацию захватывать) и накатывай скока угодно. если вообще все нужно объединить без разбору, захватывай конфигурацию рекурсивно.
(1) А можно поподробнее, "для дебилов", особенно интересует момент "положить результат в хранилище"
Захват/освобождение объектов ничего не меняет - при попытке "Конфигурация">>"Сравнить/объединить конфигурации" пишет, что редактировать нельзя и только сравнивает.
(4)Да, но на этапе "сравнить/объединить" в окне сравнения нет галок объединения, и по "выполнить" ничего не меняется.
если есть добавленные объекты, то нужно захватить корень
(5) Оппаньки. так и есть, оказывается, надо захватывать не/только объект(в моём случае справочник) целиком, но и конкретную форму.
(8)Конкретные объекты лучше целиком захватывать сразу.
Продолжение или как я сломал голову и ругался матом:
1. Создаю хранилище в боевой базе и подключаюсь к нему.
2. Цепляюсь к нему же из копии, оно говорит мне - а ты уже зауплен в другой конфе продолжить? "Ага, продолжить!"
3. Захожу конфугуратор боевой базы, авторизуюсь в хранилище, а оно мне:
"Информационная база не связана с хранилищем конфигурации".
Выглядит так, что с хранилищем единовременно можно работать одному человеку в одной базе. Поскольку это нивелирует его основной смысл, я думаю, что я всё-таки что-то делаю не так. Поможите.
Подскажите, как корректно обновлять конфигурацию, подключенную к хранилищу? Имею в виду типовые обновления от самой 1С.
1. Не совсем понятно, как правильно обновлять тестую базу, подключенную к хранилищу. Объекты то заблокированы все. Приходится отключаться от хранилища и обновляться как обычно, перенося доработки. Затем выгружаю CF и переношу на рабочую базу сравнением объединением. Опять же в рабочей так же надо захватить все объекты обновляемые, а их может быть очень много, что опять же неудобно.
2. Второе, что не понимаю. Даже, если по первому пункту я захвачу все объекты, обновляю их и загружу в хранилище обновленную версию, а затем из хранилища обновлю рабочую базу, конфигурация поставщика то у меня останется необновленной, что негодится.
В итоге при последних двух обновлениях просто отключал рабочую базу от хранилища, накатывал целиком CF (с обновлением конфигурации поставщика) и создавал новое хранилище.
Уверен, что есть путь намного короче. Прошу указать. Спасибо.
Захватываешь корень конфы, ставишь галку включать подчиненные. Все объекты захвачены. Нафига по одному объекту то?
(3) Разве? Что-то по-моему я как раз сталкивался с тем, что основная конфигурация выкачивала из хранилища только основную конфигурацию, но конфигурацию поставщика не обновляла..
(2) запустить обновление через поддержка - обновить конфигурацию, затем в окне сравнения/объединения снять галочку на корне конфигурации. Нажать применить. конфа поставщика обновится, конфа бд останется без изменений. затем уже можно из хренилища забрать изменения
(4) Значит ты что-то делал не так.
В (1) всё верно написано.
Особенность установки обновления заключается в том, что должна быть захвачена в хранилище вся конфигурация, начиная с корня.
Дальше - стандартным путём, через "Поддержка" - "Обновить конфигурацию". Дальше возможны варианты. Можно сначала обновить только конфигурацию поставщика (как в (5)), а уже потом обновлять основную конфигурацию. Но тут надо быть осторожным и следить, чтобы и удаленные из конфигурации поставщика объекты удалялись и нужное не потерялось.
После обновления и помещения в хранилище корня конфигурации и всех подчиненных ему объектов (по сути - всей конфы), все подключенные к этому хранилищу базы данных при обновлении из хранилища получат не только измененную конфигурацию, но и конфигурацию поставщика.
Основная теорема систематики: Новые системы плодят новые проблемы.
Собственно вопрос - кто что использует.
Для чистоты сравнения - опишу тривиальную ситуацию:
Есть ЦБ, есть копия ЦБ в которой кодят, потом, каким то образом - переносят изменения в ЦБ.
Собственно вопрос - кто как?
Если есть инфа по принципиальным различиям разных видов обновлений - просьба отписать, уже очень интересно понять всю суть этих процессов.
А то как то в молодости показали как обновлять, вот как то не задумываясь и обновляю :)
Если уже аналогичные ветки - просьба ткнуть носом, гугль не показал.
Идеально было бы - если бы люди поделились тем, в каком порядке что и как они обновляют.
Только просьба - не критиковать чужие решения , если человек сам об этом не просит.
Сделаем этакой сборник советов, а то вроде этой инфы куча, но она как то разбросана, не в куче, та и с выходом 8.3 может что то изменилось, кто то приоритеты или методики поменял.
Например в 8.3 удобно сохранять конфу в хмл и его пилить в историю, где можно все сравнить.
Особенно удобно макеты, не явные изменения на форме и т.д.
Переносим изменения в базу:
Сравниваем и объединяем конфигурацию ЦБ (43.31%, 55 голосов) Через файл поставки и обновления конфигурации (24.41%, 31 голосов) Обновить конфигурацию из хранилища (16.54%, 21 голосов) Я не в теме, но хочу тоже за что-то проголосовать. (15.75%, 20 голосов) Получить из хранилища (рекурсивно всю ветку) (14.17%, 18 голосов) Загружаем и выгружаем объекты конфигураций (1.57%, 2 голосов)Есть ЦБ, есть копия ЦБ в которой кодят, потом, каким то образом - переносят изменения в ЦБ.
Собственно вопрос - кто как?
хранилище разработки - самый лучший вариант для описанного примера.
Есть ЦБ, есть копия ЦБ в которой кодят, потом, каким то образом - переносят изменения в ЦБ.если сам наШкодил то сравнение. а если вышло обновление поставщика, то загрузить.
На все базы хранилище создавать муторно. не, ну если только один кодит, то можно и без хранилища, а вот если от 2х и больше, то только хранилище. Но при использовании хранилища есть баги - не все объекты корректно переносятся
(5) увы, но это так.
Буквально недавно решали с коллегой такой глюк, и дошло до абсурда - в базе появились призраки, т.е. некоторые пользователи - видят одну часть кода, другие другую.
Ни чистка кэшей, ни перезагрузка, ничего не помогало, помогло только одно - удалить базу в списке и подключить снова, причем под другим именем.
Конечно и без хранилища пару раз такой глюк был, но с хранилищем - намного чаще, увы.
Самое страшное - что не понятным образом сбились один раз настройки РЛС и некоторые пользователи видели все остатки и т.д., хотя было четкое разграничение по РЛС.
А после удаления и подключения базы - все стало ок. Короче - жесть.
Выздоровление после удаления базы как раз подтверждает, что кэш недочистили. К чему здеся ЦБ (Центральлная база) - тобишь работа с РИБ (((
Вопрос тогда - подправьте. (6) ЦБ - центральная база, и там уже не важно - РИБ она, или нет, в узли изменения из нее переносятся.
Поэтому и вопрос, про обновление ЦБ, что бы таких вопросов как у вас - не возникало :) (8) DitriX, Странно, но в опросе на форуме ни слова о ЦБ, а про100 о конфе (а сталобы о конфе без уточнения, что она на поддержке или с поддержкой и с возмножностью редактить или же вообще снята с поддержки)!
Вся трабла в том, что не могу зайти на форум и ёщё раз ответить на данный опрос (имеется ввиду отскринить для до100верной инфы) - предоставить скрин(" (9) Раз вы так настаиваете - давайте пройдемся по пунктам.
В теме я описал:
Есть ЦБ, есть копия ЦБ в которой кодят , потом, каким то образом - переносят изменения в ЦБ .
Будьте любезны поведать мне - можно ли изменять конфигурацию у базы, которая стоит на запрете редактирования?
А можно ли перенести СВОИ изменения, которые ВЫ накодили в тестовой базе - в центральную? Которая стоит на запрете.
Является ли, по выше перечисленным условиям, особенной разница между тем, снята конфигурация с поддержки или нет?
Ибо с конфы по любому должен быть снять запрет редактирования, это я надеюсь мы выяснили.
Поэтому я, честное слово, не могу понять - что вы пытаетесь доказать?
Если вы явно видите где то мою ошибку, не точность и т.д. - прошу в личку, я исправлю тему.
Но не надо сюда писать все это.
Я поднял вопрос о том, что в "Опроснике ничего не было сказано о ЦБ" - это первое .
Второе - что тема "Загрузить конфигурацию vs Сравнить и объединить vs Хранилище" - здеся я перешёл с главной страницы, на которой вообще ничего подобного не было - был только вопрос, как вносите изменения в конфигурацию!(((
Третье - что Снять с поддержки у поставить можно изменённую БД Снять / поставить с/на Поддержку !
А четвёртое и самое главное, что можно вообще делать для себя собственную поддержку Собственная поддержка - Другое использование поддержки Если Вы работаете в организации, в которой есть множество баз данных на одной и той же конфигурации, особенно с разными филиалами, то Вы можете поставить их на собственную поддержку и выпускать для них обновления. Ваша технология будет следующей: На одну из баз данных Вы накатываете изменения, например обновления 1С «сложным способом» Выпускаете обновления для всех остальных баз Остальные базы обновляются автоматическим обновлением. Технология создания таких обновлений следующая. Самостоятельное создание файла обновления производится путем сравнения сохраненной ранее CF с текущими изменениями в конфигурации. Изменения записываются в файл обновления. Поэтому при планировании создания таких файлов обновления не забывайте о необходимости наличия выгрузки до проведения изменений.
З.Ы. Пожалуй тоже оставлю))))
(11) вы вполне развернуто написали и до меня частично дошло о чем вы, но так и не дошло - зачем.
1. Есть такой бок у инфостарта, когда тупо опрос вылазит и все. Но тема то о другом может быть. Ну да ладно.
2. это в первому
3. Какое это отношение имеет к переносу изменений?
4. Ну так выберите соответствующий пункт в опросе :)
Если опишите свой способ, и расскажите какие бока у него и плюсы, то я думаю все будут только рады.
У нас была такая ситуация.
Есть сервер 1, на котором располагается основная база. База привязана к хранилищу. Есть сервер 2, на котором располагаются базы разработчиков, привязанные к хранилищу на 1-ом сервере. Разработчики получали изменения из хранилища в свои конфигурации, вносили изменения и помещали эти изменения в хранилище. После, каждый заходил на 1-ый сервер под своей учётной записью windows, заходил в базу под своей учётной записью 1С, вводил пароль для входа в хранилище (учётная запись для входа в хранилище из под этой базы естественно одна) и выполнял обновление основной базы через "Обновить конфигурацию из хранилища" или рекурсивным получением всех объектов.
Возникла периодическая проблема. Иногда, разработчик 2, зайдя в основную базу, не видел своих наработок, который он вносил ранее в основную базу. Он видел частично "старую" базу. Получение объектов из хранилища показывало, что изменений нет. При этом, если заходить из под учётной записи windows 1-ого разработчика - эти наработки были. Грешили на права к каталогу хранилища, но у всех разработчиков к этому каталогу полный доступ. Иногда помогала чистка кэша у 2-ого разработчика, но ненадолго. Пришлось отказаться от такого метода работы.
Сейчас основная база не привязана к хранилищу. Разработчики работают на 2-ом сервере в своих базах, которые привязаны к хранилищу, расположенному на этом же сервере. После внесения изменений в конфигурацию и помещения их в хранилище, разработчики переносят свои наработки в основную базу с помощью файла.
Механизм сравнения и объединения конфигураций позволяет сравнивать между собой два прикладных решения и объединять их полностью или выборочно по результатам сравнения.
Такая возможность используется, например, когда одно прикладное решение разрабатывается несколькими независимыми разработчиками, или в случае, когда в исходную конфигурацию нужно загрузить сделанные изменения.
Этот механизм обеспечивает не только сравнение общих свойств объектов прикладного решения (справочников, документов и т. д.), но и сравнение их отдельных реквизитов, табличных частей. Также выполняется сравнение форм: сравниваются тексты модулей, тексты описаний и макеты.
Все результаты сравнения можно просмотреть в детальном виде.
Установка соответствия объектов
При запуске режима сравнения система анализирует сравниваемые конфигурации и устанавливает соответствие между объектами конфигураций, исходя из их имен:
Однако не исключена ситуация, когда одинаковые объекты прикладного решения будут иметь различные имена или наоборот, различные объекты будут называться одинаково. В этом случае разработчик имеет возможность отказаться от соответствий, установленных по умолчанию, и установить их вручную:
Сравнение конфигураций
Результат сравнения конфигураций отображается в специальном окне:
Разработчик имеет возможность настроить состав информации, отображаемой в этом окне. Возможен просмотр всех объектов прикладного решения, только отличающихся, только измененных, присутствующих только в какой-либо одной конфигурации или только неизмененных объектов.
Для каждого отличающегося объекта можно просмотреть детальную информацию об отличиях:
Кроме того, информация об отличиях может быть получена в виде отчета:
Объединение конфигураций
Для выполнения объединения конфигураций следует отметить те объекты прикладного решения, которые будут участвовать в объединении и установить режим объединения конфигураций.
Установка режима объединения конфигураций возможна как для всей конфигурации в целом, так и для каждого элемента прикладного решения в отдельности:
Варианты сравнения и объединения конфигураций
Система поддерживает сравнение и объединение различных видов конфигураций. В качестве сравниваемых конфигураций могут выступать:- основная конфигурация;
- конфигурация базы данных;
- конфигурация, сохраненная во внешнем файле;
- конфигурация поставщика.
Таким образом, например, возможно сравнение двух конфигураций, сохраненных во внешних файлах, или сравнение основной конфигурации с конфигурацией поставщика.
Сохранение / загрузка настроек объединения конфигураций
Настройки объединения конфигураций (или настройки обновления конфигурации на поддержке) можно сохранять в xml файл. Также доступна и обратная операция — загрузка этих настроек из файла.
Пакетный режим запуска конфигуратора также поддерживает использование настроек при объединении и обновлении конфигураций. Таким образом при объединении конфигураций, содержащих большое количество изменений, когда объединение выполняется регулярно, существует возможность полностью автоматизировать операции сборки конфигураций.
Использование внешней программы
Существует целый ряд сторонних специализированных программ, с помощью которых можно выполнять объединение модулей. Если недостаточно встроенных возможностей 1С:Предприятия, или если хочется использовать одну из сторонних программ, есть возможность подключить её в настройках конфигуратора и использовать для сравнения, настройки объединения и собственно объединения модулей конфигурации.
Для самых распространённых программ в конфигураторе 1С:Предприятия уже содержатся параметры командной строки для их запуска в различных режимах:При желании можно использовать и другие программы, которые поддерживают запуск из командной строки. Их параметры нужно добавить в настройки конфигуратора самостоятельно.
Читайте также: