При попытке развернуть информационную базу на платформе 1С:Предприятие 8.1 под управлением современных версий СУБД (например, MS SQL Server 2012, 2014, 2016 или выше) системные администраторы часто сталкиваются с критической ошибкой: «Неподходящая версия (10.00.xxxxx) провайдера базы данных. Требуется 08.00.0194 или более поздние». Несмотря на то, что версия 10.00 значительно «позднее», чем 08.00, встроенные механизмы проверки платформы 1С не позволяют продолжить работу. Проанализируем ситуацию и разберем все доступные способы решения этой проблемы.
Прежде чем переходить к активным действиям, разберем, почему старая платформа «не видит» новую СУБД. Корень проблемы кроется в библиотеке sqlsrvr.dll, которая входит в состав сервера приложений 1С. В коде этой библиотеки используется функция sscanf для парсинга строки версии, возвращаемой SQL-сервером или OLE DB провайдером. Платформа ожидает увидеть формат версии SQL Server 2000 (08.00.xxxx). Когда современный SQL Server возвращает двузначное число в начале версии (10, 11, 12 и т.д.), парсер 1С некорректно интерпретирует эти данные или считает их не соответствующими заданному диапазону.
Самым стабильным и правильным решением является использование более современных версий платформы 1С. Рассмотрим, как это реализовать без потери функциональности вашей конфигурации на 8.1.
.dt) вашей информационной базы 8.1. В свойствах конфигурации необходимо установить «Режим совместимости» со значением «Версия 8.1». Это позволит сохранить логику работы старых механизмов, при этом используя современный движок для связи с СУБД.Если по каким-то причинам переход на платформу 8.2/8.3 невозможен (например, из-за специфических внешних компонент или требований заказчика), рассмотрим вариант модификации исполняемого кода платформы. Мы изменим условия проверки версии так, чтобы любая версия считалась подходящей.
Для реализации этого метода нам понадобится любой HEX-редактор. Разберем шаги по правке файла sqlsrvr.dll для версии 8.1.15.14 (32-бит):
C:\Program Files (x86)\1cv81\bin\).sqlsrvr.dll — это обязательный шаг!
00008D9C: заменяем 75 на EB
00008D9D: заменяем 18 на 39
00008E11: заменяем 0F на EB
00008E12: заменяем 8C на 29
00008E13: заменяем 4F на 90
00008E14: заменяем 05 на 90
00008E15: заменяем 00 на 90
00008E16: заменяем 00 на 90
Эти правки превращают условные переходы (проверку версии) в безусловные или в «пустые» операции (NOP), что заставляет систему игнорировать результат сравнения цифр версии.
Для 64-битного сервера 1С смещения в файле будут отличаться. Если вы используете x64 версию платформы 8.1, проанализируем следующие последовательности байт для поиска и замены:
FF 15 ? ? ? ? 85 C0 75 18.75 18 на EB 18.0F 8C 4F 05 00 00.EB 29 90 90 90 90.После внесения изменений сохраним файл и запустим службу 1С. Теперь проверка версии будет успешно проходиться независимо от того, что возвращает SQL Server.
Существует альтернативный подход, предложенный опытными системными администраторами. Вместо правки кода 1С можно «обмануть» сервер, подправив версию в системной библиотеке провайдера OLE DB. Посмотрим, как это сделать:
Найдем файл sqloledb.dll (в папке C:\Program Files\Common Files\system\ole db\ для x64 или C:\Program Files (x86)\Common Files\system\ole db\ для x86). В HEX-редакторе найдем строку версии, которая указана в ошибке (например, 10.00.17763), в формате Юникод. Заменим её на требуемую платформой версию: 08.00.0194. Лишние символы в конце строки следует забить нулями (00).
Важное замечание по Windows 10/Server 2012+:
При замене системных файлов или файлов в Program Files вы можете столкнуться с защитой Windows. Рекомендуем копировать файл на рабочий стол, редактировать его там, а затем копировать обратно с правами администратора. Также убедитесь, что файлы не заблокированы службой 1С или другими процессами (используйте утилиту Process Explorer для поиска блокирующих дескрипторов).
Иногда после патчинга служба 1С отказывается запускаться. Рассмотрим возможные причины:
ragent.exe, rmngr.exe, rphost.exe) в список исключений DEP.%LocalAppData%\VirtualStore. В итоге 1С будет продолжать использовать оригинальный непатченный файл из защищенной системной папки. Проверьте отсутствие копий файла в пользовательском профиле.Проанализируем частую ошибку: многие пытаются изменить уровень совместимости базы данных (Compatibility Level) в настройках SQL Server на «80» (SQL 2000) или «90» (SQL 2005). Это не поможет. Проблема в том, что 1С 8.1 опрашивает версию самого экземпляра (Instance) сервера при установке соединения, а не настройки конкретной БД. Инстанс SQL 2012 всегда будет возвращать версию 11.0, даже если для базы установлен режим совместимости с SQL 2000.
Таким образом, мы разобрали основные пути решения проблемы. Наиболее безопасным является переход на платформу 8.2/8.3, однако при необходимости работы именно на 8.1 метод HEX-патчинга остается единственным рабочим инструментом для интеграции со старым ПО.