← На главную

При активной работе в программах на платформе «1С:Предприятие 8.3» (особенно часто это проявляется в конфигурациях «1С:Зарплата и управление персоналом 3.1» и «1С:ERP Управление предприятием») администраторы и разработчики могут столкнуться с внезапным аварийным завершением работы системы. Платформа закрывается, предлагая записать дамп, либо выдает подробное сообщение об ошибке взаимодействия с СУБД:

Microsoft SQL Server Native Client 11.0: Column or parameter #3: Specified column precision 44 is greater than the maximum precision of 38. HRESULT=80040E14, SQLSrv: SQLSTATE=42000, state=1, Severity=10, native=2750

В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем физические ограничения систем управления базами данных и рассмотрим три надежных способа решения данной проблемы.

Выясняем причину возникновения ошибки

Для того чтобы понять природу этой неисправности, обратимся к внутренним механизмам взаимодействия платформы 1С и СУБД Microsoft SQL Server. При выполнении сложных расчетов (например, при автоматическом заполнении документа Ведомость в банк, подборе сотрудников или расчете страховых взносов) конфигурация выполняет тяжелые запросы с множественными соединениями таблиц, расчетом долей и агрегированием числовых данных.

Платформа 1С транслирует внутренний язык запросов в стандартный диалект T-SQL, понятный серверу баз данных. В процессе этой трансляции для промежуточных вычислений и временных таблиц динамически определяются типы данных числовых полей.

В СУБД MS SQL Server для хранения точных числовых значений с плавающей точкой используются типы данных decimal и numeric. Эти типы имеют два ключевых параметра:

1. Precision (Точность) — максимальное общее количество десятичных цифр, которые могут быть сохранены (как слева, так и справа от десятичной запятой).
2. Scale (Масштаб) — максимальное количество десятичных цифр, хранящихся справа от десятичной запятой.

Согласно официальной спецификации Microsoft SQL Server (начиная с версии 2008 и заканчивая самыми современными релизами), максимальная физически поддерживаемая точность (precision) для этих типов данных составляет строго 38 знаков.

Из-за внутренней программной ошибки в механизме трансляции запросов (компиляторе SQL-запросов) платформы 1С версии 8.3.12 (в частности, в релизах 8.3.12.1412 и 8.3.12.1440) система формирует некорректный запрос к СУБД. Платформа пытается принудительно типизировать одно из вычисляемых полей как число с точностью 44 знака (например, numeric(44, 15)). СУБД MS SQL Server отвергает такой запрос как некорректный и возвращает ошибку с кодом 2750, в результате чего сеанс работы пользователя аварийно завершается.

Способ 1. Рекомендуемое решение: Обновление технологической платформы

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

Данная ошибка была официально зарегистрирована под номером 000041723 и полностью устранена разработчиками фирмы «1С».

Проанализируем шаги по устранению проблемы с помощью обновления:

1. Перейдем на портал поддержки пользователей 1С и скачаем дистрибутив платформы версии 8.3.12.1529 или любого более позднего стабильного релиза (например, из веток 8.3.14, 8.3.16 или актуальной 8.3.22/8.3.23 в зависимости от требований используемой конфигурации).
2. Произведем установку новой версии платформы на сервере приложений 1С:Предприятие. Перед установкой обязательно остановим службу Агент сервера 1С:Предприятия.
3. Обновим клиентские приложения на рабочих местах пользователей.
4. Запустим службу сервера 1С и выполним повторное заполнение документа Ведомость в банк. Ошибка больше не повторится, так как новый транслятор запросов корректно ограничивает максимальную точность вычисляемых полей тридцатью восемью знаками.

Способ 2. Временный обходной путь: Использование файлового режима

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

Данная ошибка возникает исключительно на стороне клиент-серверного СУБД MS SQL Server. Встроенный движок файловой базы данных 1С (файл 1Cv8.1CD) использует собственные алгоритмы математических вычислений и не имеет жесткого ограничения на точность промежуточных трансляций в 38 знаков. В файловом варианте базы данных этот алгоритм отрабатывает без ошибок.

Рассмотрим по шагам, как временно провести документы в файловом режиме:

1. Откроем базу данных в режиме Конфигуратор на SQL-сервере.
2. Создадим резервную копию информационной базы, выгрузив её в файл с расширением .dt. Для этого перейдем в меню Администрирование — Выгрузить информационную базу....
3. Создадим на локальном компьютере или быстром SSD-накопителе пустую папку для файловой базы данных.
4. Запустим стартер 1С, добавим новую информационную базу без конфигурации (указав созданную ранее локальную папку).
5. Запустим локальную базу в режиме Конфигуратор и загрузим полученный ранее файл резервной копии через меню Администрирование — Загрузить информационную базу....
6. Запустим информационную базу в режиме Предприятие, перейдем в нужный документ и выполним его заполнение и проведение. Расчет заполнится корректно и без сбоев.
7. После проведения расчетов выгрузим базу обратно в формат .dt и загрузим ее на SQL-сервер. Важно: этот метод подходит только как разовая экстренная мера, так как при любой следующей аналогичной операции расчета на сервере SQL ошибка проявится снова до тех пор, пока не будет обновлена платформа.

Способ 3. Откат конфигурации (даунгрейд): Почему это опасно и как делать правильно

В процессе обсуждения проблемы часто возникает вопрос о возможности откатить версию конфигурации (сделать даунгрейд, например, вернуть ЗУП с версии 3.1.5.222 на стабильную 3.1.5.170). Рассмотрим этот аспект подробнее.

Простое использование функции «Загрузить конфигурацию из файла» (загрузка старого файла .cf поверх новой базы данных) в случае с крупными учетными решениями, такими как ЗУП или ERP, крайне не рекомендуется по следующим причинам:

• Разрушение структуры данных: При обновлении конфигурации разработчики часто меняют структуру метаданных — удаляют старые реквизиты, добавляют новые справочники, регистры сведений и накопления.
• Потеря информации: Принудительное наложение старой структуры поверх измененных таблиц SQL приведет к безвозвратному удалению данных, которые хранились в новых реквизитах, созданных при обновлении.
• Несовместимость обработчиков обновления: При первом запуске нового релиза всегда отрабатывают отложенные обработчики обновления данных, которые переносят информацию из старых регистров в новые по определенным правилам. Обратного механизма автоматического «отката данных» в платформе не существует.

Если вам абсолютно необходимо вернуть базу к предыдущему релизу конфигурации, единственным корректным способом является восстановление базы данных из резервной копии (бэкапа), сделанного непосредственно перед обновлением. При этом все данные, введенные пользователями после обновления, придется переносить вручную или с помощью специализированных обработок выгрузки-загрузки данных через XML.

Поэтому в ситуации с ошибкой precision 44 откат конфигурации является нецелесообразным. Гораздо быстрее, проще и безопаснее обновить саму технологическую платформу 1С до стабильного релиза.