При попытке развернуть старую версию платформы 1С:Предприятие 8.2 (особенно релизы ниже 8.2.19) на современных операционных системах вроде Windows 10 или Windows Server 2016/2019 в связке с MS SQL Server 2012/2014, администраторы часто сталкиваются с критической ошибкой: "Неподходящая версия (10.00.xxxxx) провайдера базы данных. Требуется 08.00.0194 или более поздние".
Ситуация кажется парадоксальной: система сообщает, что ей нужна версия 08.00 (соответствует SQL Server 2000), видит версию 10.00 (соответствует современным ОС) и при этом утверждает, что она "неподходящая". Разберем по шагам, почему это происходит и как это исправить, не прибегая к обновлению платформы, если оно запрещено условиями поддержки программного продукта.
Проблема кроется в алгоритме проверки версии системного OLE DB провайдера (библиотека sqloledb.dll), который зашит в программный код платформы 1С. Разработчики старых релизов 1С использовали строковое сравнение версий. С точки зрения логики платформы, строка, начинающаяся на "10", оказывается "меньше" строки, начинающейся на "08".
Проанализируем ситуацию: Windows 10 поставляется с обновленным компонентом Data Access Components, где версия провайдера совпадает с номером сборки ОС (например, 10.00.19041). Платформа 1С считывает этот номер и, из-за ошибки в логике сравнения, считает его устаревшим. Мы рассмотрим три метода решения этой проблемы: от локального патча 1С до модификации системных библиотек Windows.
Если нам необходимо решить проблему только для конкретного сервера 1С, наиболее правильным путем будет отключение проверки версии провайдера непосредственно в файле платформы. Для релиза 8.2.15.294 (x32) процедура выглядит следующим образом:
C:\Program Files (x86)\1cv82\8.2.15.294\bin\).sqlsrvr.dll и обязательно создадим его резервную копию.Рассмотрим конкретные смещения (offsets) и байты, которые необходимо заменить, чтобы превратить условные переходы (проверки) в безусловные или "пустые" инструкции:
00001750: заменяем 75 на EB
00001751: заменяем 16 на 35
000017BF: заменяем 0F на EB
000017C0: заменяем 8C на 29
000017C1: заменяем 4F на 90
000017C2: заменяем 05 на 90
000017C3: заменяем 00 на 90
000017C4: заменяем 00 на 90
После внесения правок сохраним файл и запустим службу сервера 1С. Эти действия заставляют платформу игнорировать результат проверки версии SQL-провайдера, и база данных успешно создается.
Этот метод считается более универсальным, так как он "обманывает" платформу, подсовывая ей ожидаемый номер версии прямо из операционной системы. Посмотрим на алгоритм реализации этого метода:
Проанализируем файл C:\Windows\SysWOW64\sqloledb.dll (для 32-битной 1С на 64-битной Windows). Нам нужно изменить информацию о версии, которая зашита внутри файла в формате Unicode.
TrustedInstaller на текущего администратора и предоставим себе полный доступ.10.00.19041). Эту строку можно увидеть в свойствах файла sqloledb.dll на вкладке "Подробно".08.00.0194. Если новая строка короче старой, оставшиеся символы забиваем нулевыми байтами (00).Важный нюанс: Этот метод влияет на всю систему. Если другие приложения на сервере жестко требуют 10-ю версию провайдера, они могут работать нестабильно. Однако для выделенных серверов 1С это решение является самым быстрым и эффективным.
Если 1С не может договориться с OLE DB, она может попытаться использовать старый протокол DB-Library. В современных версиях Windows файл ntwdblib.dll отсутствует. Попробуем восстановить его работу:
Найдем файл ntwdblib.dll от версии SQL Server 2000 или 2005 (версия файла должна быть примерно 2000.80.2039.0). Поместим этот файл непосредственно в папку bin сервера 1С. В некоторых случаях платформа автоматически переключится на использование этого драйвера, и проверка версии OLE DB будет пропущена.
Рассмотрим важный аспект работы с SQL Server 2014. Платформа 1С 8.2.15 изначально проектировалась для работы с уровнем совместимости базы данных (Compatibility Level) 80 (SQL 2000) или 90 (SQL 2005). В MS SQL 2014 минимально доступный уровень — 100 (SQL 2008).
Посмотрим, как настроить базу данных после того, как мы обошли ошибку провайдера:
Compatibility level в значение SQL Server 2008 (100).Проанализируем риски: работа на уровне 100 для платформы, рассчитанной на уровень 80, может приводить к ошибкам в запросах, использующих специфические типы данных (например, Datetime2). Если после патча 1С падает с ошибкой при выполнении отчетов, рекомендуется убедиться, что в конфигурации не используются типы данных, несовместимые со старой платформой.
Мы выяснили, что наиболее стабильным сочетанием в условиях жестких ограничений является патч sqlsrvr.dll в сочетании с ручным созданием пустой базы данных через SQL Management Studio и последующим подключением её в консоли 1С. Это позволяет избежать ошибок на этапе инициализации структуры базы данных сервером 1С.
Если ваша задача — поддержка разработки, мы рекомендуем использовать Windows Server 2008 R2 в качестве виртуальной машины. Это избавит вас от необходимости "патчить" бинарные файлы и обеспечит нативную поддержку SQL Server 2005/2008, с которыми платформа 8.2.15 работает наиболее корректно.