код счета стал неуникальным 1с
Ошибка при обновлении
Если наблюдать за системой в момент ошибки то видно что процесс 1с занимает памяти около 4GB но свободной памяти еще около 9Gb.
Причем если запустить базу еще раз то опять поинтересуется легальностью обновления опять запустит обновление информационной базы но далее все произойдет штатно откроется окошко которое расскажет нам о прелестях новой версии.
Люди добрые, подскажите на сколько велика вероятность того, что в момент этой ошибки, что то потеряется или сломается в инф. базе.
Были ли у кого нибудь подобные прецеденты как решали или я один такой рукожопый.
И еще где-то читал что на одной машине нельзя запускать сразу третью и вторую платформу при обновлении будут ошибки, не знаете какие должны быть ошибки.
Спасибо, и спасибо всем кто откликнулся вот что сделал.
v1.Берем чистую 11_0_9_14 загружаем туда наш dt
v2.Отключаем регламентные задания
v3.Изменяем заголовок
v4.Загружаем стандартные правила
v6.Очищаем адресный классификатор
v5.Удаляем версии объектов
v6.Отключаем версионирование полностью
v7.Делаем резервную копию.
v8.Загружаем чистый CF 11_0_9_14 для постановки на поддержку
v9.Обработка РегистрацияИзмененийДляОбмена82 удалить всю регистрацию изменений для всех объектов
v10.Делаем резервную копию
v11.обновление конфигурации через цфу 11_0_9_15 и обновление инф базы
v12.обновление конфигурации через цфу 11_1_2_8
v13.Делаем резервную копию.
v14.обновление инф базы 11_1_2_8 старт 13:00 05.02.14 ОКОНЧАНИЕ без ошибки 13:40 06.02.14
скорее всего помогла очистка регистрации изменений, или отключение параноидального версионирования объектов (как то с психу включил и забыл)
Платформа: 1С:Предприятие 8.3 (8.3.4.408)
Конфигурация: Управление торговлей, редакция 11.1 (11.1.2.28)
Продолжаю обновляться через cfu до версии 11.1 (11.1.4.10)
При анализе конфигурации до реструктуризации помимо предстоящих изменений в базе выдает три предупреждения
1.Объект изменен: Справочник.ВидыКонтактнойИнформации
Справочник.ВидыКонтактнойИнформации. Старые предопределенные данные будут удалены, возможно образование зависших ссылок на предопределенные данные
Регистрация изменена: Справочник.ВидыКонтактнойИнформации
2.Объект изменен: Справочник.НастройкиХозяйственныхОпераций
Справочник.НастройкиХозяйственныхОпераций. Старые предопределенные данные будут удалены, возможно образование зависших ссылок на предопределенные данные
Регистрация изменена: Справочник.НастройкиХозяйственныхОпераций
3.Объект изменен: ПланВидовХарактеристик.РазделыДатЗапретаИзменения
ПланВидовХарактеристик.РазделыДатЗапретаИзменения. Старые предопределенные данные будут удалены, возможно образование зависших ссылок на предопределенные данные
С этим можно жить, или необходимо что-то предпринять?
После обновления БГУ на 1.0.49.4
Вот еще одно подтверждение того, что первые релизы с таким серъёзным реформированием всегда содержат ошибки и не конца потестированы.
Лучше подождать или на копии, проверять и принимать решение.
Коллеги, вчера обновился (ЗКБУ на платформе 8.3.9.2033) с 1.0.48.5 на 1.0.49.4.
Полагаю, тем у кого описанные проблемы, косяки следует искать в своих базах.
Добрый день.
Спасибо за предложенные решения проблемы. Пока справляемся очищением в правом углу даты.
Но эти неактуальные счета участвуют в контроле дублирования записей регистра.
Еще комментарий по делу:
В обновлении добавлены два новых реквизита в элемент плана счетов: ДатаНачала и ДатаОкончания (недоступных для редактирования на форме). В форме выбора счета добавлен отбор по некоей дате актуальности. Однако, у некоторых клиентов после обновления все без исключения счета имеют период начала и окончания равный пустой дате, из-за этого всякий раз выборе счета нужно очищать соответствующее поле ввода на форме. У других клиентов дата оконачания ставится 01.01.2999, что позволяет выбрать счет. Закономерности этой ошибки при этом мы не выявили, но это точно не связано с логической либо физической целостностью (либо утилиты платформы эти проблемы не выявляют). Регистр рабочих счетов здесь не при чем, со второй вкладки формы выбора счета выбираются без проблем.
Еще один комментарий:
И самое плохое в текущей ситуации то, что все ошибки скрытые. При обновление явного сообщения о ошибке нет. Все проявляется при тек. работе. А учитывая массовость данной ошибки, это явно очень негативный момент.
PS. Не поняла, зачем период действия счетов в плане счетов привязывать к рабочим счетам в обработке обновления? Разве этот период не регламентирован инструкциями? Почему его нельзя програмно проставить в зависимости от номера счета, или подчинения к какому-либо счету (в том случае, когда пользователем добавлен субсчет какого то конечного счета). Не лучше ли привязывать период к рабочим счетам только к добавленным пользователем счетам, т.е. к тем которые не регламентированы.
И это только малая часть. Нормально давать такое обновление в конце года?