Бухгалтерию версии 2.0 (базовая) обновляла сама. Подскажите при переходе на 3.0:
1. Версия платформы 8.2.19.80, какую платформу 3.0 ставить?
2. При обновлении конфигурации, какой платформой запускать 2.0 или сразу 3.0?
(1) smr63,
1. Ставить всегда последнюю
2. Если не ошибаюсь, переход начинается в 2.0, значит и запускаться нужно на 8.2. Уже потом обновленную базу открывать на 8.3.
Раньше БП 3.0 и на 8.2 запускалась.
(5) tolyan_ekb, можно конечно помудрить и сделать разные ярлыки, но по умолчанию 8.3 заменяет стандартный starter и чтоб запускать в 8.2 нужно указывать необходимую платформу в настройках базы, по аналогии как с разными релизами платформы 8.2 это делается
Дело в том что я приняла изменения и закрыла. При запуске ошибок не было.
Некоторые объекты справочников были помечены на удаление.
А где посмотреть какие предупреждения?
(12) smr63, теперь поздно пить Боржоми, когда почки отвалились!(с) Народная мудрость. если делали копии, можно повторить на копии и увидеть эти ошибки.
(14) smr63, там диалог после обновления конфигурации, в нем кнопки принять, отмена и еще что то, если ползунок сдвинуть вниз то можно увидеть где есть предупреждения.
После обновления семь строк с восклицательными знаками:
! Код справочника стал неуникальным: УдалитьТерриториальныеУсловия (МКС)
! Код справочника стал неуникальным: УдалитьТерриториальныеУсловия (РКС)
! Предопределенные виды характеристик, измененные пользователем, содержат тип, не соответствующий типу значений плана видов характеристик: ВидыСубконтоХозрасчетные
! Предопределенные виды характеристик, измененные пользователем, содержат тип, не соответствующий типу значений плана видов характеристик: УдалитьНазначенияСвойствКатегорийОбъектов
! Код вида характеристики стал неуникальным:УдалитьНазначенияСвойствКатегорийОбъектов (00000000121)
! Код вида характеристики стал неуникальным:УдалитьНазначенияСвойствКатегорийОбъектов (00000000122)
! Предопределенные виды характеристик, измененные пользователем, содержат тип, не соответствующий типу значений плана видов характеристик: УдалитьНастройкиПользователей
Предупреждения при обновлении через конфигуратор вылезают довольно таки часто, бояться этого не стоит. Если доступна (видима) кнопка "Принять" - значит обновление пройдет, а выведенное в предупреждения удалится или будет изменено. Предупреждения связаны с тем, в что в обновлении сделали изменения в структуре данных, которые приводят к тому, что имеющаяся в ИБ информация в новой структуре или не нужна, или должна быть каким то образом изменена.
Я уже давно не обращаю внимания на эти предупреждения, если "Принять" видна.
В ситуации, когда кнопки "Принять" не видно уже необходимо смотреть на предупреждения, т.к. там написано, какие объекты в ИБ (в смысле данные) мешают принятию изменений. В этом случае делаю так:
- открываю в режиме учета;
- открываю справочник (или регистр или...), прописанный в предупреждении;
- удаляю оттуда всё.
После этого обновление проходит...
(28) Alex_E, спасибо, я пробовала на копии, все помеченные объекты удаляются после обновления. База уже три года, вот я думаю обновить ее до версии 3.0 или с января лучше завести новую. И стоит ли перед обновлением делать тестирование и исправление базы.
(29) smr63, ТИИ никогда не помешает - чем дольше "живет" база - тем более вероятны всякие баги в ней. Я вообще стараюсь сворачивать каждый год - ради формирования акта сверки в один клик заставлять пользователей работать в еле "ворочающейся" базе, и сидеть часами с обновлением - не моё :-)
(31) Prikum, Да хоть в 10, реально работают каждый день, и ждать при выписке документов или открытия оборотки - это перевесит любую проверку, которая таки не каждый день приходит. У меня был клиент, сидевший в типовой УПП, с данными за 5 лет, которая не обновлялась, просто потому, что никто не мог дождаться окончания обновления - надо работать, а база "занята". "Такой футбол нам не нужен!" Практикую свертку со времен 7.7 (работаю с 1С с 2000г.). Клиенты сами уже просят свернуть, как год закроют, и никаких проверок не боятся. акты сверки за 3 года то же не каждый день нужны.
Выгрузка в excel есть, сложить можно и там. Ну и совсем на крайняк - никто не запрещает держать для таких эксклюзивов "накопительную" копию.
просто потому, что никто не мог дождаться окончания обновления - надо работать, а база "занята".
Вы путаете причины и следствия.
Дождаться обновления не могли либо потому, что база стояла на медленном/"псевдо" сервере, либо потому что сервер не был настроен. А уж ни как не потому, что
(34) h00k, Вы уверены? Клиент был "не мой", но там был не сервер, а кластер серверов, как по крайней мере админы утверждали. Документооборот огромный, причем не только купи / продай, но и полный цикл производства, со спецификациями, планированием итд. В базе работало одновременно до полсотни пользователей...Ну Вам наверное виднее.
(35) Alex_E, просто этим клиентам не надо было так игнорировать процесс обновления, и видать они просто не могут дождаться реструктуризации таблицы проводок по БУ и НУ, потому что само обновление не очень зависит от количества лет в базе.
(36) Prikum, Этим клиентам конечно нужно было ставить обновления регулярно, а не запускать так как я увидел, НО
само обновление не очень зависит от количества лет в базе.
- утверждение неверное. Если при обновлении происходит рекструктуризация данных, например того же регистра сведений, накоплений или регистра бухгалтерии, то от количества записей время обновления очень даже зависит - просто пример - два дня пытался обновить БП 2.0, не помню какой релиз в котором в регистре сведений адресеый классификатор даже не состав реквизитов поменяли, просто порядок следования измерений. В ту базу ихний умник загрузил ВЕСЬ КЛАДР. Обновил только после его очистки. Так что в каких то случаях размер базы (а это как ни крути, напрямую зависит от количества записей, и чем больше базе лет, тем их больше) не влияет на время обновления, а иногда влияет, вплоть до невозможности обновить вовсе. А там речь шла об УПП, с её практически всегда "весёлыми" обновлениями.
(38) Prikum, А я и не говорю, что сохранение изменение кода зависит от размера базы. Весь этот "базар" возник вследствии того, что я высказал своё мнение, что стоит доводить базу до состояния хранения учета за несколько лет, воизбежании проблем с её "неповоротливостью" и в том числе тех же проблем с обновлениями. Ведь как раз в обновлениях ОЧЕНЬ часто меняется не только код, но структура таблиц...
А по поводу скорости работы пользователей - то в той же БП сравните время "отклика" базы на действия пользователя в базе за несколько лет и в свернутой за текущей год - уверен почувствуете разницу...
мои клиенты сворачивают базу после проведения выездной проверки
А если абстрагироваться от бухгалтерии? В торговых и торгово-производственных базах самая ценная информация - история продаж и т.п.. Свертка базы эту информацию "убивает" и из-за этого могут возникнуть финансовые потери например.
Если руководство это понимает, то инвестирует в оборудование и специалистов, если нет - выполняется свертка базы...
история продаж и т.п.. Свертка базы эту информацию "убивает" и из-за этого могут возникнуть финансовые потери например
- вот тут согласен, что история продаж важна, но где я "призывал" убивать базы прошлых периодов? Получить эту историю можно и используя например "самопальный" отчет, который эту историю соберет из нескольких источников, или воспользоваться Фабрикой отчетов от 1С (про 1С:Консолидацию не будем - это уже совсем круто). ИМХО - тут вопрос все ж таки в подходе наверное, кому то проще купить на несколько лямов крутое железо (таких ОЧЕНЬ мало), а кто то вложится в разработку, и получит то же самое, с использованием гораздо меньших ресурсов.
А по поводу скорости работы пользователей - то в той же БП сравните время "отклика" базы на действия пользователя в базе за несколько лет и в свернутой за текущей год
Разницы почти нет, ну, не считая некоторых микросекундных задержек из-за кэширования.
Но у вас опять путаница, поэтому верны и мое утверждение и ваше. Все упирается в то, что мы работаем на разном оборудовании и поэтому результаты такие разные.
Во, самая моя любимая часть в описании проблем. Примите за аксиому - "админы живут в параллельной реальности и о проблемах производительности 1С даже не догадываются"... бывают конечно исключения, но чаще всего стандартный ответ: "Сервер работает как часы! Это программисты накосячили, вот к ним и обращайтесь..."
но там был не сервер, а кластер серверов
Возможно отсюда у проблемы ноги и росли. Тут с настройкой одиночного то сервера приходится прилично повозится, а нормальная настройка кластера 1С-ного еще более сложная задача. Причем часть проблем, без активного изучения партнерского форума, вообще не решаема.
Документооборот огромный, причем не только купи / продай
На самом деле деградация производительности не так сильно зависит от размера базы и типа нагрузки, эти параметры больше влияют на подбор оборудования и планирование архитектуры решения.
При правильной настройке сервера и организации файлов данных пользователи вообще не заметят разницы в скорости работы между базами 10Гб и 300Гб... особенно если всего то 50 пользователей.
и время обновления никак не связаны, а вот количество записей, которые это обновление должно обработать связано напрямую, и как ни настраивай сервера всё по итогам упрется в чтение/запись с винтов. Если базу нельзя "остановить" на пару /тройку суток для обновления, то оно становится в принципе невозможным, а вот свернутую базу обновить легко - там таки записей меньше.
P.S. Про админов я в курсе - но есть ещё "объективная реальность", против которой не попрешь. На своем рабочем компе я уже второй год использую SSD, потому как часто получается, что у клиента стоят крутые брендовые сервера, клиент-сервер итд. Но сервера тупо "пятилетней давности" и их базы обновляю на своём компе, потом заливаю обратно - там уже не получается сделать обновление к концу года (если база сворачивается ежегодно). А когда там пяток лет, то ревут (точнее ревели) уже операторы. Да и мне своего времени жалко - сидеть несколько часов, чтобы увидеть любимую ошибку все времен и народов "Недостаточно памяти"...
и как ни настраивай сервера всё по итогам упрется в чтение/запись с винтов.
Проблема которую можно решить за деньги - это не проблема, это дополнительные расходы. (с)
Да и мне своего времени жалко
Я конечно понимаю, всех денег не заработать, но зачем жалеть ваш основной "продукт"?! Если есть подозрения что работать придется на устаревшем оборудовании то оплата либо почасовая, либо умноженная на коэффициент х2(х4).
ИМХО - тут вопрос все ж таки в подходе наверное, кому то проще купить на несколько лямов крутое железо (таких ОЧЕНЬ мало), а кто то вложится в разработку, и получит то же самое, с использованием гораздо меньших ресурсов.
Не, тут вопрос в целесообразности. В каких-то случаях оптимальней вложиться в программистов, в других - в оборудование. Но, стоит учитывать, что вложение в оборудование всегда приносит результат быстрее.
(46) h00k, Сколько людей столько и мнений, но проблему чтения/записи решить можно....до определённого количества этих записей - какой бы высокой эта скорость ни была - она есть, соответственно время на обработку будет = КоличествоЗаписей * ВремяОбработкиОднойЗаписи. Если записей будет ОЧЕНЬ много - будет затрачено так же ОЧЕНЬ много времени, никуда от этого не денешься.
вложение в оборудование всегда приносит результат быстрее.
- спорно - оборудование имеет свойство устаревать не физически, а морально, причем иногда это происходит "неожиданно" быстро. Сейчас "бум" вроде прошел, новые процы давно уже не появлялись (относительно давно)...но что будет завтра?
Забыл сказать - хороший сисадмин на сегодня редкость к сожалению, иногда его наличие решает кучу проблем, а отсутствие всегда создаёт ещё большую кучу на ровном месте...
База уже три года, вот я думаю обновить ее до версии 3.0 или с января лучше завести новую.
На последней версии платформы, 8.3.5.1119, обновление проходит без особых проблем и эксцессов.
Новую базу стоит заводить если:
1. Особенности ведения учета не позволяют выполнить корректное обновление штатными средствами.
2. База достигла физических ограничений на размер внутреннего файла базы данных, а покупка лицензии на сервер 1С предприятие невозможна.
3. Базы установлены на калькуляторе и открытие списка документов выполняется мучительно долго.
И стоит ли перед обновлением делать тестирование и исправление базы.
Вообще, необходимость и частота запуска ТиИ больше зависит от режима работы базы. Но даже для файловых баз есть смысл запускать раз в месяц для реиндексации, пересчета итогов и сжатие таблиц базы данных.
При смене версии платформы, например переход с 8.2 на 8.3, желательно выполнить реструктуризацию таблиц.
Пользовательские виды содержат тип, не соответствующий типу значений плана видов характеристик: ДополнительныеРеквизитыИСведения
Мы делали доработку, чтобы в характеристиках (используем как партии) были указаны документы поступления товара.
И после обновления это слетело! Приложил скриншот.
Конфигуратор об этом и сообщил!
После обновления на копии в доп реквизитам очистились данные.
Поэтому применять такое обновление нельзя!
Нужно восстановить типы данных, но если потеря данных не критична, то конечно можно допустить такое обновление!
Через расширение это доступно:
ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения: Изменение типов недопустимо в режиме совместимости 8.3.17 и ниже. Увы пока на 8.3.16 нужно доработать конфигурацию.
(48) Когда делается обновление нетиповой конфигурации, и есть добавленные/измененные типы данных, то о них голова должна болеть у разработчика, и ДО принятия изменений типы должны быть приведены в соответствие, чтобы ничего не пропало (этот косяк проходили ещё в стародавние времена, когда использовал бухгалтерию строительных организаций от Импульс ИВЦ , та в регистре Резервы по сомнительным долгам регулярно терялась аналитика по документам, добавленным в документы расчетов).
Не понятно, что значит Ваше
а вот и нет.
- - типа надо бояться предупреждений что ли? Их надо читать, если база настроенная то внимательно читать, если необходимо, то принимать меры, когда это возможно...
По Вашей ситуации я настройки для измененных баз всегда делаю на специально заведенной для этих целей копии, при начале работы системы автоматом контролирую наличие всех изменкний типовой, и просто запрещаю запуск, если что то слетело...
И, в любом случае, всегда есть копия ДО обновления, из которой даже очищенные данные в реквизите всегда можно восстановить после исправления.
Хотя, если, куякуякивпродакшен, то да - бояться надо, ОБЯЗАТЕЛЬНО НАДО))))
(49) просто я получил сегодня это сообщение и вы написали, да жми ОК всё в порядке будет...
Да, проблемы нету, кроме потери данных. В рабочей базе это было бы не приемлемо. А сам доп реквизит стал составным со всеми типами, которые ему были доступны для справки.
Но конечно же я делал это на копии, только копии до не было. Нужно будет бекап из рабочей подымать и оттуда уже повторно накатывать 6 обновлений, хотя в црм все 9. Но это будет через хранилище уже намного быстрее!
(50) я вообще то писал про переход типовой на типовую, а тут потеря данных, которые сами настроили и сами же потеряли, это да, несомненно моя вина((( каюсь...должен был 10 лет назад предусмотреть все варианты, на которые кто-то может налететь...
А с переходом что так поторопились? можно было б ещё на 2.0 посидеть...
(51) так, а что в типовой не будет потери данных? Если есть обработчик, который это восстанавливает, то нормально в ином случае тоже самое будет.
Ошибка просто в первый раз вылезла, а тут ваш "добрый совет"=)) Но зато повторно накачу все обновления, чтобы сделать замер простоя рабочей базы, спасибо и на этом!
А по поводу обновлений. Список такой:
УТ для РБ 3.4.7.155
Обновляю на 3.4.8.85, 3.4.9.98, 3.4.10.94, 3.4.11.102, 3.4.12.110, 3.4.13.282, 3.4.14.181, 3.5.8.383, 3.5.11.73.
В прошлом году только выпустили обновление модуля црм на последние релизы УТ, да и меня пару лет как у клиента не было вот и затянулось. А так да, считай 5 лет не обновляли, ну это с даты выхода первых релизов.
Ошибка просто в первый раз вылезла, а тут ваш "добрый совет"=))
- ещё раз простите великодушно.. как раз десять лет прошло с того совета, и наконец-то кто-то налетел...ну не подумалось мне тогда, что Вы вот так им воспользуетесь и потеряете данные. По этому поводу давным-давно писал https://infostart.ru/1c/tools/333873/ - вот этим пользуюсь всегда, если работаю с измененной типовой, в которой влез в реквизиты (встраиваю в измененную базу и не даю ей стартануть, если что то пропустил при объединении, потому как до этого часто приходилось восстанавливать данные из копии ДО обновления)...
Но зато повторно накачу все обновления, чтобы сделать замер простоя рабочей базы, спасибо и на этом!
- вообще непонятно , зачем так извращаться? Если есть исходная база, в которой эти данные на месте, то проще взять их оттуда и записать в исправленную обновлённую...но, НЕТ, лучше не советовать, а то опять буду плохим))))
(53) обработка интересная возьму на заметку. Так время на перенос уйдет уйма там миллионы объектов, час реструктуризация шла только, плюс нужно все равно оттестировать, я там похоже пару релизов расширений потерял...
К теме статьи вообще вопросов нету. Просто яндекс по строке:
Пользовательские виды содержат тип, не соответствующий типу значений плана видов характеристик: ДополнительныеРеквизитыИСведения
Выдал эту статью. Так что срок давно не играет роли как видите, но зато разобрали вопрос более детально!