привет друзья!
Обновляю не типовую бп 3.0
Делаю по фильтру дважды измененные свойства - что нужно оставляю из основной конфигурации, Вопрос: есть 3 базы с одинаковой конфой, можно ли обновить одну а потом залить ЦФник в другие? или нежелательно?

https://yadi.sk/i/1by4Xh7rrGAIew

конфа одинаковая если или на поддержке дописок или получена загрузкой конфы, все остальные - три разные конфы

Я обычно делаю примерно так
1 - обновляю затирая дважды измененные, чтобы не было проблем с обработчиками
2 - объединяю с готовой нетиповой конфой нового релиза (она обычно готовится на обновлении копии)

(2) да полностью одинаковые

(3) 1 - обновляю затирая дважды измененные, чтобы не было проблем с обработчиками - это как?

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

(6) Да

(6) и записку на стену "те две из этой одной через загрузку конфигурации!!11!"

(7) +

(6) но только через сравнить/объединить, не вздумай накатывать cf

(10) Загружать тоже вполне можно

(10) а что может случиться?

(12) северный пушистый зверёк (с)

(12)
1. Добавленные метаданные могут получить другие ИД. При последующей загрузке цф таблицы пересоздадутся/очистятся
2. Конфигурация поставщика не обновляется

То есть я правильно понимаю, что можно
1) Сделать копию рабочей базы
2) "Копию" обновить
3) Из неё "Сохранить конфигурацию в файл"
4) В "рабочей" базе через сравнить-объединить с "выгруженной" базой сделать обновление.
Я правильно понял?

(15) Вместо пункта 4 можно снять основную конфу рабочей с поддержки и загрузить в нее полученную на шаге 3

(16) разве?
а как же обновление данных на этапе захода в 1с предприятие?

а не обновление конфигурации

(13) каковы причины зверька?

какой профит от манипуляций? параллельно обновлять все три - намного дольше получается?

(17) Это уже пятый пункт

(19) просто некоторым не нравится такой способ - накатить загрузкой из файла.

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

(20) заметно дольше. Иногда даже критично бывает.

(19) у нас разок характеристики предопределенные йопнулись. Из бекапа базу доставали.
Ибо гуиды в поставке не совпадали с гуидами в базе

Но это было достаточно давно, сейчас вроде как за этим следят, но шанс того что что то пойдёт не так - он есть и отличен от нуля

(24) А на гуиды в поставке как-то можно посмотреть?

(26) конечно, в полной поставке есть cf его можно выгрузить в xml и посмотреть

(27) Я как-то пытался. Просто не увидел их там. Хотя искал не гуиды. Может просто не обратил на них внимания.

(28) но они там есть https://yadi.sk/i/S7WgsRDuD1OQGA

(24) Это когда происхождение базы, на которой готовилось, отличается от происхождения базы, к которой применяется обновление.
В случае же (15)
"1) Сделать копию рабочей базы
2) "Копию" обновить"
ничего такого быть не может.

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

Мда... но ведь в самом деле, не будешь же каждый раз проверять, что при получении хз откуда готового ЦФ у этих идентификаторов значения не изменятся?

(31) Зачем проверять? Просто никогда не используй сравнение для переноса изменений(особенно при добавлении метаданных) в рабочую базу. Только загрузка цф.

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

(32) и вот к чему твой сарказм?

У тебя по РИБ базы никогда не глючили?
А ведь такая же точно херня - если прилетает измененный объект метаданных, то он тупо вкорячивается в текущую без каких-либо сравнений.

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

(32) +100 однозначно правильный подход, но только при условии, что все источники cf подконтрольны

кстати при обновлении через "сравнить объединить" есть флажок "заменять внутренние идентификаторы", это позволяет накатывать только часть объектов но в режиме полной идентичности

(36) ну да, это тоже интересный режим - рискованный, скажем так

(33) Это не сарказм, а практика. Если конфигурация находится под твоим контролем, то проблемам просто неоткуда взяться. Если обнова тебе пришла извне, то проблемы ты увидишь при реструктуризации (без просмотра ИД метаданных).

То есть разбираться с кривыми ИД приходится только в одном случае: кривообновленная конфа полученная в наследство. Но даже в такой ситуации проще потерять данные и перенести их из копии чем сопоставлять ИД метаданных. Мегабаз с кривыми обновлениями по идее быть не должно.

(38) я так потерял 2 базы ЗУП, когда они поле типового обновления покрашились... а перенос данных из старой зуп в новую - это совсем не тривиальная задача как может показатся на первый взгляд

(39) архивы и бэкапы - это не роскошь, а суровая необходимость.

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

(39) С причинами разобрался?

Перенос данных между двумя базами с одинаковыми конфигурациями (без учета ИД метаданных) задача тривиальная - ВыгрузкаЗагрукаXML. Проблема может быть с объемом и скоростью, но редко:
1. как правило ломаются свежедобавленные метаданные (объем данных небольшой)
2. большие базы не должны жить в кривых руках

(40) так архивы были... но я не смог никакими ухищрениями обновить базу без последствий, пришлось делать новую и переносить со старой данные, ушло 2 недели

(41) >>>Перенос данных между двумя базами с одинаковыми конфигурациями (без учета ИД метаданных) задача тривиальная - ВыгрузкаЗагрукаXML.

ха-ха-ха

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

(41) кстати причина была в кривых начислениях удержаниях (точно не помню), в одном почему-то использовался формат datetime2 вместо datetime (хоть они и совместимые, но не очень) и еще какая кто засада с идентификаторами в предопределенных групах верхнего уровня была,

я писал в 1с, они ошибку приняли и отнесли ее на платформу...

(43) Предопределенные конечно чистятся при необходимости.

"пока опция не включена в базе нет физической таблицы" а вот это бред чистой воды

(45) не бред, можешь посмотреть в SQL...

разумеется при отключении опции уже созданные таблицы не удаляются

(46) Ты серьезно? Я константу переключил и в SQL пошли создаваться? .. в режиме предприятия при разделенном доступе...

Фантастика, может конечно с развитием расширений и придем к такому когда-нибудь с КОРП лицензиями.

Сейчас без использования расширений таблицы SQL создаются исключительно при реструктуризации

(47) да именно так :) заметь - создание а не изменение, это операция безопасная, на нее блокировки не нужны

(48) Не 1-е апреля же ещё)
До тестового SQL не скоро доберусь.
А в файловой тоже так? С прогулки вернусь, могу проверить

(49) в файловой не знаю, возможно то-же так...

хотя вот нашел

https://flagman.top/about-business/ehkzamen-1s/obekt-1s-funkcionalnye-opcii
Функциональные опции и их параметры не влияют на состав базы данных: все таблицы и поля присутствуют в БД независимо от состояния функциональных опций.

(51) Это и искать не надо. ФО только на интерфейс влияют. Не то что таблицы - вся объектная модель работает без каких-либо ограничений... и уж никаких проблем с xml-сериализацией

(51) таблица присутствует,но в нее записать на дадут,пока опция не включится,насколько я помню,а в получить структуру хранения она будет выдаваться.

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