Уважаемые специалисты, скажите пожалуйста, насколько безопасен для базы способ загрузки конфигурации поставщика через Конфигурация->Загрузить конфигурацию из файла? И насколько этот способ полезен с точки зрения скорости обновления?

Кто-то все у всех объектов включил редактирование с сохранением поддержки и теперь обновление еле ползет.

(0) Просвещайся:
https://its.1c.ru/db/metod8dev#content:2299:hdoc

Полезен, делай

(1)+(2) спасибо за помощь. А какова вероятность, что именно в бухгалтерии с поддержки снял объекты франч (чтобы дольше обновлялось), а не программист-фикси, которому вообще в бухгалтерии менять нечего?

Это к гадалке. И фотографию хаспа не забудь )))

(4) А ключ зачем? Особенно если он программный. А про гадалку - это да - спрашивать не с кого...

(3) Зачем увеличивать время обновления? Чудно как-то.

(3) Посмотри в ЖР

(6) Так приходящий обновленец больше на почасовке заработает ))

(8) Такие обновленцы быстро становятся одноразовыми.

(7) а по какому событию искать?

(10) Вряд ли найдёшь. Но это не важно. Восстановил и забыл.

(10) Проверь и узнай

сняли с поддержки, что бы перескочить через несколько релизов.

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

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

Вернуть не изменённые метаданные на поддержку - это несколько нажатий кнопки мыши, ничего сложного.

(14) расскажи как, а то мы не в теме....

(13) а базе от таких скачков не плохеет?

(16) вполне может и поплохеть, хотя вероятность не очень большая, на мою оценку от 1 до 5% риск, что "что-то пошло не так" при таких обновлениях...

(15) Открыть конфигурацию поставщика, сравнить

(18) сравнить и дальше? давай уже дальше :) особенно если версия конфы различается с версией поставщика в базе...

"если версия конфы различается с версией поставщика в базе" - надо сначала их сравнять.
А потом (18) и изменить режим поддержки

(20) что делать если при попытке поставить из (18) будет сообщение о возможной потери данных ?

(21) При попытке изменить режим поддержки - не будет.
Это может быть только если что-то удалять из конфигурации. Это уже несколько более иначе другой вопрос.

(22) а вот и нет, есть пример из жизни когда в зупе внутренний идентификатор реквизита плана расчета не совпал с тем что на поддержке. в результате реструктуризации этот реквизит очистился и конфа ушла в даун....

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

(23) а в таких случаях при пересчете данных, когда сохранении конфигурации БД - это видно - выдается предупреждение, что реквизит очищен?

(0)Вот только на скорость обновления вся эта байда никак не повлияет. Скорость растет только если конфа без возможности изменения, а если возможность включена, то никакие замки не спасут.

(25) после Конфигурация->Загрузить конфигурацию из файла возможность изменения отключается и в настройке поддержки появляется кнопка "Включить возможность изменения".

И еще - какая к лешему возможность изменения в бухгалтерии? В лучшем случае только внешние обработки.

(27) "какая к лешему возможность изменения в бухгалтерии?" // Так у некоторых там полноценный УУ, а у некотрых - работа с ТО. Норм.

(0) безопасно и полезно

(28) и бухгалтерия терпит долгое обновление такой базы, особенно в период отчетности?

(29) спасибо, а кроме проверки остатков / оборотов по счетам что еще лучше сделать после возврата на поддержку?

(30) Конечно: для целей бухии онлайн 24х7 в базе пользователю сидеть не требуется

(28) за полноценный УУ в регламенитрованной базе БП, надо руки отрывать. я сам таким был когда-то, но это было сильно по молодости...

(32) для ларька, где директор, главбух и начсклада в одном лице наверное потянет. Особенно при почасовке для программиста.

(23) К установке "замка" это не имеет отношения

(15) "расскажи как, а то мы не в теме" - если фраза будет изменена на "... а то Я не в теме" - расскажу. "Мы" тут не к месту. Мы, т.е. ты и я. А я -"в теме".

Всего лишь нужна ещё одна база - донор конфигураций "на поддержке".

(15) Не торгуйся с гражданином. Тратить силы на преодоление такой убежденности - непродуктивно )

(34) +1 его пост скорее к кривым ручкам предыдущих обновляльщиков, чем к проблемам обновления. Я тоже встречал в своей практике неоднократно случаи несоответствия метаданных. Нужно быть чуток более внимательным, вовремя это увидеть и ликвидировать, не доводя дело до потери данных.

(36) было на (35) , извините

(38) Упс :)

На самом деле, ничего сверх-секретного в возврате на поддержку конфигурации нет и не было. Вариантов действий - множество и неоднократно всё описано в различных источниках.

(39) Согласный. Но я о другом. Об отсутствии необходимости убеждать. Зачем оно?

Ну... это, как бы, было сказано не только для vde69. Если ТС будет интересно - поищу ссылки. Но его, если я его правильно понял, интересует несколько другой аспект возврат на поддержку.

(3) Какой дурак будет увеличивать время обновления? Есть такие?

(13) А зачем снимать с поддержки? Неужто перескочить несколько релизов без снятия нельзя?

(42) Ты не поверь как много дураков, которые ради изменения всего только одного объекта конфигурации, легким движением задней клешни, изменяют правило поддержки на "Объект поставщика редактируется с сохраненнием поддержки" по всем подчинённым объектам корня конфигурации.

Sorry, "Ты не поверь" --> "Ты не поверишь"

(44) Скорее просто невнимательность. При обновлении переключатели не так поставят. Которые "Режим поддержки для новых объектов" и т.п.

Ситуация с изменением поддержки прояснилась - у нас база УТ11 - старая (11.1), а бухгалтерия - самая свежая и замки в бухгалтерии сняли, чтобы восстановить старый способ обмена. Я только не понял - неужели чтобы вернуть старый обмен нужно включить изменение всех объектов?

(47) Нет, не нужно. Но это просто быстрее, чем выбирать отдельные объекты.

(44) В это-то я как раз поверю.
Таких долбодятлов сотни.
Но вот чтобы специально снимать с поддержки для увеличения времени обновлениея - с таким не сталкивался.

(49) причина найдена - в (47)