Зачем запускать базу в режиме предприятия после каждого обновления?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Если обновляете через конфигуратор - то после каждой "ступени" обновления нужно заходить в Предприятие банально для того, чтобы закрепить изменения внутри ИБ.
Если вы зайдете в предприятие спустя н-ное число ступеней есть шанс, что база банально "сломается".
Если обновляете через конфигуратор - то после каждой "ступени" обновления нужно заходить в Предприятие банально для того, чтобы закрепить изменения внутри ИБ.
Если вы зайдете в предприятие спустя н-ное число ступеней есть шанс, что база банально "сломается".
(22) В общем случае - запускать надо после КАЖДОГО обновления. Другой вопрос - каждое ли обновление надо ставить? Тут поможет только подбор цепочек - ставить не все подряд, а максимально только те новые релизы, которые поддерживают обновление текущего релиза.
Нехитрая логика.
Нехитрая логика.
(1)
Что значит нет базы? А что тогда обновляем, только для получения cf файла?
К примеру, я обновляю через конфигуратор, для обновления забираю только cf, зачем мне запускаться каждый раз режим предприятия, ведь у меня данных базы все равно нет, что бы обработчики с ними отработали
Что значит нет базы? А что тогда обновляем, только для получения cf файла?
(12) Подумал что мало ли, вдруг еще один способ. Еще совсем недавно не знал что можно cf-ником обновлять. Оказывается это так быстро, розницу 2.2.12.30 до 2.3.8.27 одним махом обновить. А франчи за каждый промежуточный ключевой релиз по тарифу счет выставляют.
(8)Даже в пустой базе должны быть заполнены кое-какие данные (справочники со ставками налогов, процентных ставок и т.д.). И эти данные обновляются именно обработками, которые запускаются первыми после обновления. Без этих данных некоторые вещи могут поломаться.
(0) Например есть БСП.
В нёй - справочник "ИдентификаторыОбъектовМетаданных" а у него в Модуле менеджера: ВыполнитьОбновлениеДанных
которая перезаполняет его при обновлении...
И вызывается она только в режиме Предприятия (клиента)...
Вот такая история...
З.Ы. Есть и другие истории про обновление
В нёй - справочник "ИдентификаторыОбъектовМетаданных" а у него в Модуле менеджера: ВыполнитьОбновлениеДанных
которая перезаполняет его при обновлении...
И вызывается она только в режиме Предприятия (клиента)...
Вот такая история...
З.Ы. Есть и другие истории про обновление
Если база пустая, то проще свои доработки перенести в новую конфигурацию последнего релиза.
Если такой вариант не подходит, то можно взять и выгрузить обработкой XML данные из пустой конфигурации последнего релиза(в этом варианте нужно быть более внимательным к данным)
Либо каждый раз запускать конфигурацию в режиме предприятия, после каждого обновления. Как написали ранее.
Если такой вариант не подходит, то можно взять и выгрузить обработкой XML данные из пустой конфигурации последнего релиза(в этом варианте нужно быть более внимательным к данным)
Либо каждый раз запускать конфигурацию в режиме предприятия, после каждого обновления. Как написали ранее.
(20) Разницы нет откуда обновлять. Если это типовая CF из поставки - то она работает точно так же как и CFU. А вот если вы самостоятельно раздобыли где-то CF типовой, да еще снятую с поддержки, и пытаетесь обновиться с помощью сравнения и объединения... То тут вы сами себе злобный буратино.
Вот не соглашусь с большинством , недавно была тема по поводу обновления через промежуточные релизы или сразу cf "ебнуть" так вот после перехода в режим предприятия база данных так же последовательно обновляется ( можно видеть по журналу регистрации) . Если скачек очень большой то система не даст обновить конфигурацию в режиме предприятия.
(21)
Опытные чуваки доверяют платформе и отработанному годами механизму, ибо знаю цену потерянным данным.
Если скачек очень большой то система не даст обновить конфигурацию в режиме предприятия.
Только самонадеянный новичок будет обновлять базу в режиме Предприятия. Ну, за исключением базовых версий.
Опытные чуваки доверяют платформе и отработанному годами механизму, ибо знаю цену потерянным данным.
(25) не так выразился - имеется ввиду запуск 1с предприятия после обновления в конфигураторе , хотя Вы могли бы меня понять , так как недавно с Вами спорили в указанной мной теме и там был показ скрин ошибки которая может возникнуть при обновлении с помощью cf при большом скачке релизов
(27) можно конкретный пример ( с какого на какой релиз через обновление cf теряются данные) ? Я вам уже показывал обновление с 3.0.60 до 3.0.103 одним релизом с помощью cf . Потерь данных не наблюдалось , с учетом того что промежуток между релизами очень большой и там 100% были изменения в структуре реквизитов регистров , документов , справочников . Так же было показано обновление с более раннего релиза и соответствующая ошибка.
(46) Про всегда я не говорю. во-первых встречаются редко , во-вторых есть определенные случаи когда этот способ может сэкономить время . Например в том году в отчетный период попалась компания которая давно не обновлялось - а отчеты сдать нужно . Не нужно быть слишком категоричным.
(44) Да-да, обработчики тоже со временем удаляются из программного кода. Опять же - на картинке нетиповая функциональность. Вот команда разработки БП попыталась как-то на прикладном уровне контролировать обновления. А в остальных конфигурациях такого не предусмотрено (это же не платформенный контроль, а написанный такими же программистами на встроенном языке 1С)..
Еще раз - абсолютно частный случай конкретного прикладного решения, не более.
Еще раз - абсолютно частный случай конкретного прикладного решения, не более.
(28)
Нет, конечно можно сначала провести сравнение и объединение (без примерения к ИБ), проанализировать весь состав конфигурации на наличие удаляемых объектов, проштудировать все составные и определяемые типы на предмет исключения из них индивидуальных ссылочных и примитивных типов. И только потом, будучи в полной уверенности - обновлять.
Но стоит ли?
Я вам уже показывал обновление с 3.0.60 до 3.0.103 одним релизом с помощью cf . П
Это всего лишь означает, что между этими релизами не было удаления метаданных, а было только добавление (включая расширение составных и определяемых типов). Частный случай, не более. Тем более это БП, которая вообще редко изменяется. Ну или это было удаление метаданных в неиспользуемых учетных областях данной компании (расчет зарплаты, как пример).
Нет, конечно можно сначала провести сравнение и объединение (без примерения к ИБ), проанализировать весь состав конфигурации на наличие удаляемых объектов, проштудировать все составные и определяемые типы на предмет исключения из них индивидуальных ссылочных и примитивных типов. И только потом, будучи в полной уверенности - обновлять.
Но стоит ли?
(28)
Если непонятно, что означает это сообщение о невозможности запуска, так смысл в том, что 1С позволяет изменить структуру метаданных (в Конфигураторе), но преобразовать данные (в Предприятии) в соответствии с новой структурой - уже невозможно. И чтобы пользователь не продолжил свою работу в базе, целостность которой нарушилась при обновлении, он видит такое сообщение и рекомендации по исправлению ситуации.
Что тут непонятного? Да, необязательно запускать Предприятие после каждого обновления, но через какие-то ключевые релизы перепрыгивать нельзя. Какие именно - знает только 1С и не торопится делиться этим знанием - ее право.
можно конкретный пример ( с какого на какой релиз через обновление cf теряются данные) ?
Чем вас не устраивает из ветки, на которую вы сами ссылаетесь в (21)?
Если непонятно, что означает это сообщение о невозможности запуска, так смысл в том, что 1С позволяет изменить структуру метаданных (в Конфигураторе), но преобразовать данные (в Предприятии) в соответствии с новой структурой - уже невозможно. И чтобы пользователь не продолжил свою работу в базе, целостность которой нарушилась при обновлении, он видит такое сообщение и рекомендации по исправлению ситуации.
Что тут непонятного? Да, необязательно запускать Предприятие после каждого обновления, но через какие-то ключевые релизы перепрыгивать нельзя. Какие именно - знает только 1С и не торопится делиться этим знанием - ее право.
(50) Блин , Вы читаете мои посты или нет . Я как раз это и утверждаю. Я прошу пример при котором не будет выдано данное сообщение , но будут потеряны данные. И если прошлую ветку почитаете там точно такое же смысл - система не даст полностью обновить информационную базу если сильно изменилась конфигурация
(51)
Судя по всему, в ERP 2.5.7 эта возможность не используется еще со времен 2.4.7, например.
если сильно изменилась конфигурация
Если бы вы попытались посмотреть в коде, как это реализовано, то поняли бы - никакого каонтроля "сильно ли изменилась конфигурация" - там нет. Это просто инструмент БСП, который предоставляет разработчику возможность ограничивать такие обновления. Но не обязывает. Не удивлюсь, если в последующих версиях БСП её вообще удалят.
Судя по всему, в ERP 2.5.7 эта возможность не используется еще со времен 2.4.7, например.
(51)
Спрашивается - а нафига это нужно, нам всем хором вас уговаривать? Да обновляйтесь как хотите, и лучше без резервной копии... чтобы однажды наступившее "счастье" было максимально полным. ;)
Блин , Вы читаете мои посты или нет
А вы читаете не только мои посты или нет? Пока я писал свое сообщение, вам уже три раза про все объяснили - и про то, что "предохранители" не везде встроены, и про то, что со временем они могут удаляться и т.д.
Спрашивается - а нафига это нужно, нам всем хором вас уговаривать? Да обновляйтесь как хотите, и лучше без резервной копии... чтобы однажды наступившее "счастье" было максимально полным. ;)
(53) Не нужно меня уговаривать - не маленький. Я говорю лишь то , с чем сам встречался и сам проделывал. Еще раз я повторюсь , что бывают ситуации когда обновление с помощью cf оправдано , есть ли "защита от дурака" нужно смотреть - например обновить копию базы и проверить.
(54)
Есть рекомендованная 1С последовательность релизов при обновлении, при соблюдении которой разработчик гарантирует сохранность данных базы.
Все прочее - на ваш страх и риск, и хватит уже тут сиськи мять.
Не нужно меня уговаривать - не маленький.
Правда? Непохоже...
Я говорю лишь то , с чем сам встречался и сам проделывал.
"Неоднократно переходил дорогу в неположенном месте, и никогда ничего плохого со мной не случалось."
Еще раз я повторюсь , что бывают ситуации когда обновление с помощью cf оправдано
Флаг в руки, барабан на задницу!
Есть рекомендованная 1С последовательность релизов при обновлении, при соблюдении которой разработчик гарантирует сохранность данных базы.
Все прочее - на ваш страх и риск, и хватит уже тут сиськи мять.
(51) Да как вы понять не можете, что к тому времени, как вы получите некое сообщение об ошибке в режиме предприятия, данным УЖЕ придет большой пушной зверь?
Еще раз спрошу: вам реально не жалко своего времени? применение изменений конфигурации может ОЧЕНЬ на долго "подвесить" систему и после этого вы можете получить сообщение о том, что обновление не может быть выполнено.
Т.е. вам придется восстановить БД из бэкапа и начать обновление заново.
Еще раз спрошу: вам реально не жалко своего времени? применение изменений конфигурации может ОЧЕНЬ на долго "подвесить" систему и после этого вы можете получить сообщение о том, что обновление не может быть выполнено.
Т.е. вам придется восстановить БД из бэкапа и начать обновление заново.
(58) Давайте сравним время обновления последовательно и через cf даже с ошибкой , Возьмем пример 3.0.45 по 3.0.103 , как выяснили мне для обновления нужно сделать 2 обновление cf с учетом восстановления из архивной копии . Но Вам при обновлении последовательно нужно обновить как минимум 58 релизов и если вы говорите что это подвешивает систему то кто больше времени потратит я 2 релиза + восстановление или вы 58 релиз + заход в базу для выполнения обработчиков
(60)
Потому что на самом деле - 36 обновлений:
3.0.47.2, 3.0.48.22, 3.0.49.23, 3.0.50.12, 3.0.51.20, 3.0.52.32, 3.0.53.39, 3.0.57.10, 3.0.59.43, 3.0.60.44, 3.0.61.47, 3.0.64.21, 3.0.64.54, 3.0.66.53, 3.0.67.67, 3.0.68.66, 3.0.70.41, 3.0.71.77, 3.0.72.70, 3.0.73.60, 3.0.75.37, 3.0.75.109, 3.0.76.77, 3.0.77.95, 3.0.79.14, 3.0.81.23, 3.0.82.40, 3.0.84.46, 3.0.87.28, 3.0.88.32, 3.0.89.56, 3.0.91.36, 3.0.95.29, 3.0.99.21, 3.0.103.12, 3.0.103.21
ЧСХ, в этой цепочке иногда можно "прыгать" аж через 3-4 релиза, а иногда - надо накатывать последовательно, а 3.0.75 - аж 2 релиза!
Почему - предоставляю вам догадаться самостоятельно.
Вам при обновлении последовательно нужно обновить как минимум 58 релизов
Угу, именно это я и подозревал. Ваше утверждение про "58 релизов" однозначно говорит о том, что вы никогда не имели доступа на
Потому что на самом деле - 36 обновлений:
3.0.47.2, 3.0.48.22, 3.0.49.23, 3.0.50.12, 3.0.51.20, 3.0.52.32, 3.0.53.39, 3.0.57.10, 3.0.59.43, 3.0.60.44, 3.0.61.47, 3.0.64.21, 3.0.64.54, 3.0.66.53, 3.0.67.67, 3.0.68.66, 3.0.70.41, 3.0.71.77, 3.0.72.70, 3.0.73.60, 3.0.75.37, 3.0.75.109, 3.0.76.77, 3.0.77.95, 3.0.79.14, 3.0.81.23, 3.0.82.40, 3.0.84.46, 3.0.87.28, 3.0.88.32, 3.0.89.56, 3.0.91.36, 3.0.95.29, 3.0.99.21, 3.0.103.12, 3.0.103.21
ЧСХ, в этой цепочке иногда можно "прыгать" аж через 3-4 релиза, а иногда - надо накатывать последовательно, а 3.0.75 - аж 2 релиза!
Почему - предоставляю вам догадаться самостоятельно.
(64)
Если у вас есть время сидеть считать сколько релизов нужно ставить
Неее, у меня есть время (и привычка) спросить Гугль, втыкайте:
это про вопрос о том кто ценит свое время.
Это - не вопрос, это - ответ: кто уважает мнение других, а кто - только свое, "единственно верное".
(73)Если работа не сделана(а она не сделана, т.к. целостность данных БД нарушена), то смысла нет вообще о чем-то дальше разговаривать.
Ваша задача доказать, что целостность данных при "большом скачке" не нарушается, коль скоро вы заявляете, что берете всю ответственность на себя.
Ваша задача доказать, что целостность данных при "большом скачке" не нарушается, коль скоро вы заявляете, что берете всю ответственность на себя.
(60) 1. Давайте сравним, при условии, что вы гарантируете целостность данных после обновления 3.0.45 на 3.0.103 пусть даже в 2 захода.
2. для последовательного обновления с 3.0.45 на 3.0.103 потребуется 35 итераций, после которых лично я гарантирую целостность данных. Если целостность нарушится, то можно смело подавать в суд на 1С, по причине выпуска "деструктивного" обновления.
2. для последовательного обновления с 3.0.45 на 3.0.103 потребуется 35 итераций, после которых лично я гарантирую целостность данных. Если целостность нарушится, то можно смело подавать в суд на 1С, по причине выпуска "деструктивного" обновления.
еще раз для всех !!! при обновлении cf я понимаю что, беру риски на себя . Еще раз я не утверждаю что этим способом можно постоянно обновляться !! еще момент ситуации когда встречается большой разрыв крайне редки ( спасибо нашим законодателям) . Я лишь утверждаю что при переходе через несколько релизов обработчики выполняются для каждого релиза поэтому я не вижу смысл после каждого обновления заходить в режим предприятия. Так же мои утверждения касаются того что система не позволит обновить конфигурацию если изменения слишком серьезные ( но опять же как тут высказали многие эта защита от дурака может быть не во всех конфигурациях)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот