В процессе администрирования и поддержки крупных конфигураций на платформе 1С:Предприятие 8.3 (таких как «1С:Комплексная автоматизация 2» или «1С:ERP») специалисты часто сталкиваются со сложными системными сбоями при синхронизации данных в распределенных информационных базах (РИБ). Особенно остро эти проблемы проявляются после проведения масштабных обновлений конфигурации.
В этой статье мы подробно разберем природу возникновения критической ошибки "String data, length mismatch" (HRESULT=80004005), проанализируем, почему стандартные механизмы обмена дают сбой, и рассмотрим пошаговые методы её устранения — от быстрого аварийного обхода проблемы до глубокой системной настройки сервера СУБД.
Давайте разберем, что именно сообщает нам система в тексте ошибки:
Ошибка при выполнении файловой операции 'v8srvr://Server/base/configsave/...new' по причине: Ошибка СУБД: Microsoft SQL Server Native Client 10.0: String data, length mismatch. HRESULT=80004005
Эта ошибка относится к категории низкоуровневых сбоев СУБД (код состояния ODBC/OLE DB — SQLSTATE 22026). Она возникает не на уровне прикладного кода конфигурации, а при взаимодействии платформы 1С с СУБД Microsoft SQL Server через установленный драйвер клиента.
Выделим основные причины сбоя:
Config (основная) и ConfigSave (динамическая или сохраняемая) в виде бинарных данных большого объема (BLOB) в полях типа image или varbinary(max).ConfigSave СУБД ожидает данные строго задекларированного размера. Ошибка String data, length mismatch указывает на то, что фактически переданный драйвером пакет данных оказался длиннее или короче, чем было заявлено платформой в заголовке SQL-запроса. Транзакция аварийно прерывается сервером СУБД.---
Если сроки сдачи отчетности поджимают и обмен нужно восстановить немедленно, воспользуемся обходным путем, который успешно применили участники обсуждения на форуме. Мы принудительно обновим конфигурацию узла РИБ из файла, чтобы базе не приходилось принимать «тяжелый» пакет изменений через транспортный XML-файл обмена.
Поскольку в периферийной базе конфигурация заблокирована для редактирования главным узлом, стандартно загрузить её нельзя. Нам потребуется временно отключить узел от РИБ, применить обновление и подключить его обратно. Рассмотрим этот процесс по шагам:
Шаг 1. Выгрузка конфигурации из Центрального узла
.cf (например, central_update.cf).Шаг 2. Отключение периферийной базы от главного узла
// Отключаем признак подчиненности периферийного узла
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого кода периферийная база перейдет в автономный режим, а замок с конфигурации будет снят.
Шаг 3. Загрузка конфигурации в периферийную базу
central_update.cf.Шаг 4. Восстановление связи с главным узлом
Запустим периферийную базу в режиме «Предприятие» и выполним код для возврата базы в распределенную структуру:
// Восстанавливаем связь с центральной базой
СсылкаНаЦентр = ПланыОбмена.НайтиПоКоду("ЦБ"); // Укажите реальный код вашего центрального узла
Если Не СсылкаНаЦентр.Пустая() Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
Сообщить("Связь с главным узлом успешно восстановлена.");
Иначе
Сообщить("Узел с указанным кодом не найден!");
КонецЕсли;
Шаг 5. Запуск стандартной синхронизации
Теперь запустим стандартный обмен РИБ. Так как конфигурации в обеих базах идентичны, платформа пропустит передачу тяжелых файлов метаданных и успешно синхронизирует только накопленные документы и справочники, завершив отложенные процедуры обновления данных.
---
Чтобы окончательно устранить первопричину сбоя String data, length mismatch на уровне СУБД, нам необходимо обновить устаревший драйвер подключения.
SQLNCLI10 на SQLNCLI11 или MSOLEDBSQL).Использование современного драйвера гарантирует корректную работу с большими пакетами бинарных данных конфигураций уровня ERP/КА без падения сетевых пакетов.
---
Часто рассинхронизация размеров пакетов вызвана тем, что в кэше сервера приложений 1С зависают устаревшие версии метаданных, ссылающиеся на несуществующие структуры в таблице ConfigSave. Выполним полную очистку кэша сервера приложений по следующему алгоритму:
services.msc.C:\Program Files\1cv8\srvinfo\reg_1541\.1a2b3c4d-5e6f-...).snccntry, config, conftemp. 1Cv8Log) и файлы настроек самого кластера.---
Если транзакция обмена упала посреди процесса, в СУБД могли зависнуть временные «грязные» записи в таблицах конфигурации. Даже если таблица ConfigSave кажется пустой при просмотре через консоль 1С, на уровне базы данных там могут содержаться фантомные строки. Выполним безопасную очистку таблиц метаданных:
-- Переводим базу в однопользовательский режим для очистки таблиц
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- Очищаем таблицы хранения временной конфигурации
TRUNCATE TABLE dbo.ConfigSave;
TRUNCATE TABLE dbo.ConfigCASSave;
-- Возвращаем многопользовательский режим
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
GO
Это действие полностью безопасно для пользовательских данных и позволяет убрать любые незавершенные транзакции реструктуризации конфигурации.
---
Если проверка базы данных с помощью команды СУБД DBCC CHECKDB показывает отсутствие физических повреждений, это не исключает логических ошибок во внутренних индексах таблиц метаданных платформы 1С.
Для восстановления внутренней логической структуры таблиц рекомендуется выполнить классический цикл выгрузки-загрузки базы данных через файл резервной копии:
backup.dt.backup.dt.Этот процесс заставит платформу физически пересоздать структуру всех таблиц 1С (включая индексы к полям BLOB) на сервере SQL с нуля, что гарантированно устраняет любые логические несоответствия длин полей.
---
Версии платформы ветки 8.3.12 (например, используемая автором темы 8.3.12.1790) были выпущены достаточно давно и содержали ряд недоработок при взаимодействии механизма SDBL (внутреннего транслятора запросов 1С) с СУБД MS SQL Server при обновлении тяжелых конфигураций.
Рекомендуется обновить платформу 1С:Предприятие на сервере приложений и на рабочих станциях пользователей до актуальных стабильных релизов (например, веток 8.3.21, 8.3.22 или выше).
В новых версиях платформы разработчики оптимизировали работу буфера обмена, уменьшили объемы временных данных, записываемых в таблицу ConfigSave, и исправили ошибки, приводившие к некорректной работе функции SQLPutData в драйверах SQL Native Client.
Подведем итоги: Внезапная ошибка String data, length mismatch — это системный конфликт драйвера базы данных и платформы при передаче тяжелых метаданных. Использование аварийного обновления через выгрузку-загрузку файла .cf позволяет быстро восстановить работу РИБ в критических ситуациях, а обновление драйверов SQL и платформы 1С навсегда защитит базу от повторения этой проблемы в будущем.