Доброго времени суток, уважаемые специалисты.

База2 создана путем копирования каталога Базы1. Затем в Базу2 были внесены необходимые справочники и документы, которые потом были выгружены в Базу 1 с помощью обработки ВыгрузкаЗагрузкаДанных - при такой выгрузке ГУИДы выгруженных объектов получаются одинаковыми в обеих базах

Потом было замечено:
1.выгружаем конфигурацию Базы1 в файл
2. Открываем конфигуратор Базы2. Конфигурация - Сравнить с конфигурацией из файла. Сравнение идет очень долго (хотя конфигурации идентичные). В итоге после долгого процесса сравнения выходит пустая таблица отличий, т.е. конфигурации обеих баз совпадают. Медленное сравнение говорит о том, что ГУИДы метаданных не совпадают, правильно?
3. Правильно. Значит нужно сделать, чтобы ГУИДы метаданных совпадали. Для этого хочу в конфигураторе Базы2 сделать - конфигурация - Загрузить конфигурацию из файла. После этого процесс сравнения будет проходить быстро.

Вопрос: при загрузке конфигурации из файла не слетят ли ГУИДы объектов в базе2? Ведь если слетят, то при следующей выгрузке данных и Базы2 в Базу1 в Базе1 произойдет задвоение загружаемых объектов (если таковые уже были в Базе1)

заранее благодарю за помощь

(0) Выгрузи в XML и сравни

(0) да

Одно непонятно..
Ты слепил База 2, добавил в ней новые справочники и документы. Т.е в База1 нет этих объектов еще ?

(2) на каком этапе ГУИДы разъехались-то? Если в процессе тут на всех этапах ГУИДы одинаковые.

(4) подождем автора, а то не понятно, что он понимает под термином " Базу2 были внесены необходимые справочники и документы,"

это он сами данные внес, или cf поправил.. Если данные, то вообще пофик и делать ничего не надо

(0) Если База2  была получена путем копирования, то НЕТ, идентификаторы существующих объектов не изменятся

никакого задвоения не произойдет. ГУИДы выгружаемых объектов не изменились же. А на ГУИДЫ метаданных при стандартной выгрузке/загрузке (не через SQL) наплевать

(0)
2. нет

(4) на каком этапе разъехались гуиды - непонятно. с базой работали несколько человек...
И вообще, медленное сравнение, объединение с конфигурацией из файла означает, что разъехались гуиды метаданных?

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

Базы очень большие что ли? Что-то мешает сделать тестовые загрузки на копиях и убедиться?

(11) базы небольшие, можно и тестовые загрузки на копиях сделать, но предварительно хотел узнать у специалистов, верны ли мои догадки

повторюсь: Медленное сравнение, объединение с конфигурацией из файла означает, что разъехались гуиды метаданных?

(13) не знаю, что именно там разъехалось. Может просто реструктурирование нужно, потому что конфиг из базы ну очень долго считывается пообъектно.

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

Сравнение и объединение прямо на сервере (не загрузка из файла, а сравнение) оно реально медленное. На некоторых серверах бывает быстрое. На других медленное. Это скорее поведение сервера, а не конкретного периферийного узла.

Размер ЦФ-ки какой и включена на сервере конфигурация поставщика или она выпилена давным давно?

(15) база2 файловая, размер сф = 1,2гб где-то, упп ред.1.3

(13) см (8)

угу. они почти всегда долго делают сравнение и объединение. Если в режиме сервака, то можешь ускорить процесс, если уберешь признак редактирования конфигурации с сохранением поддержки.

при загрузке конфигурации из файла не слетят ли ГУИДы объектов базы данных в базе2?

если ты пишешь, что 2 была скопирована раньше из 1, а теперь ты сохранил цф-ку из 1 и хочешь загрузить ее из файла в 2 - не слетят.

(19) При копировании базы (файла, средствами БД или через dt) ГУИДы метаданных поменяться не могли. Если ГУИДы метаданных всё-таки разные, то загрузка cf их восстановит, но данные потеряются при реструктуризации.

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

У меня сложилось впечатление, что 1С сначала сравнивает объекты конфигурации по хешам (как вариант - контрольным суммам), и если хеши не совпадают - сравнивает уже полностью. А если совпадают - считается, что объекты одинаковые. Полное сравнение гораздо медленнее, в то время как хеши могут проверяться с очень высокой скоростью.

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

(23) Реструктуризация при этом была? Сравнение стало быстрее?

(24) реструктуризации вроде не было - или просто не успел увидеть, быстро прошла

успел увидеть только состояние "обработка структуры базы данных"

сравнение стало быстрее: было 6мин, стало 5сек

полностью сравнил идентификаторы справочника Номенклатура, контрагенты, плана счетов бухучета - идентификаторы этих объектов не изменились. Можно считать значит, что дальнейший обмен через ВыгрузкаЗагрузкаДанных пойдет без задвоений объектов базы данных?

(26) Что-то ты теплое с мягким путаешь. ВыгрузкаЗагрузкаДанных работает по ГУИДам данных, идентификаторы метаданных там никаким боком.

(25) Интересный результат. Спасибо.

(27) поэтому и спрашивал, повлияет ли загрузка конфигурации из файла на работу обработки ВыгрузкаЗагрузкаДанных. Получается, что НЕ повлияет. Спасибо всем за помощь

(28) кстати, я когда на УПП плотно разрабатывал, то у меня в конфигурацию была умышленно добавлена никому не нужная Константа с типом Строка и я время от времени на строке менял длину, затем применял к базе. Оно запускало реструктуризацию всех мета... при том, что ничего критичного для разработки я не трогал :-) Лайфхак от Фрэнки