Содержание:

1. Рутинное обновление баз клиента БП 3.0

2. Откат бэкапа в 1С, повторное обновление

Либо задан сомнительный параметр @objname, либо требуемый @objtype (object) является ошибочным.

Рутинное обновление баз клиента БП 3.0

Рутинное обновление баз клиента БП 3.0 с релиза 3.0.159.23 на 3.0.162.22 на платформе версии 8.3.25.1336 в 64-х разрядном режиме. Вдруг на последней базе выскочила незнакомое сообщение:

Незнакомое сообщение

После перезапуска конфигуратор предложил завершить сломавшееся обновление и, спустя некоторое время, успешно открылся. Сделанное тут же ТИИ ничего криминального не обнаружило.

Однако, после запуска в режиме предприятие процедуры обновления завершились нештатно:

Невосстановимая ошибка

Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:

по причине:

Ошибка СУБД:

Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта “dbo._InfoRgChngR41340X1”.

HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1

Откат бэкапа в 1С, повторное обновление

Откат бэкапа в 1С, повторное обновление. На этот раз только 1 сеанс 1С, с отслеживанием доступной оперативной и дисковой памяти. Ошибка повторилась.

Что происходит? Имя таблицы _InfoRgChngR говорит, что это таблица регистрации изменений регистра сведений. Суффикс X1 означает что объект принадлежит расширению конфигурации. В базе действительно стоит расширение, в котором сделано 3 независимых регистра сведений, но они не участвуют в планах обмена. Отключаю расширение, повторяю обновление. Ошибка остается. Полностью удалить расширение нельзя, поскольку приведет к физическому удалению объектов расширения 1С вместе с живущей в них информацией, потеря данных клиента неприемлема.

Откатываю бэкап в 1С, повторяю обновление, под включенным профайлером MS SQL сервера, на этот раз заранее создаю недостающую таблицу скриптом T-SQL:

CREATE TABLE [dbo].[_InfoRgChngR41340X1](

         [_NodeTRef] [binary](4) NOT NULL,

         [_NodeRRef] [binary](16) NOT NULL,

         [_MessageNo] [numeric](10, 0) NULL,

         [_Fld41713_TYPE] [binary](1) NULL,

         [_Fld41713_RTRef] [binary](4) NULL,

         [_Fld41713_RRRef] [binary](16) NULL,

         [_Fld1087] [numeric](7, 0) NOT NULL

) ON [PRIMARY]

Обновление закончилось падением на аналогичной ошибке, но уже с другим номером таблицы.

Проблема не в одном «больном» регистре сведений, а носит массовый характер.

Снова откат на исходное состояние. Традиционные меры при непонятной ситуации: перезагрузка 1С и MS SQL, чистка кэшей, выгрузка/загрузка в dt. Обновление. Снова знакомая ошибка. Обновление на другой релиз БП закончилось аналогично.

Помогло включение «экспериментального» режима обновления

https://its.1c.ru/db/v8314doc#bookmark:dev:TI000002111

Почему обычный режим реструктуризации вдруг сломался, а новый режим успешно справился осталось загадкой. Единственное что можно уверенно утверждать – новые релизы платформы не только исправляют старые ошибки, но и дарят нам новые и еще незнакомые.

Подозрительно, что проблемная база оказалась единственной, в которой стояло расширение с объектами данных.

С моей точки зрения это аргумент в пользу подхода к разработке: новые поля и таблицы создавать в основной конфигурации, в расширения помещать только код. Очевидный плюс такой методики – в случае проблем расширение можно безболезненно удалить из базы, а потом установить снова. Добавленные поля и объекты не конфликтуют типовыми и, при правильном подходе к именованию – не забываем использовать префиксы, не усложняют обновление.

Специалист компании ООО “Кодерлайн”,
Дорошенко Андрей