← На главную

При запуске клиентского приложения 1С или при попытке обращения сервера приложений к базе данных может возникать критическая ошибка СУБД следующего вида: Microsoft SQL Server Native Client 11.0: Поставщик именованных каналов: не удалось открыть соединение с SQL Server [5]. HRESULT=80004005, SQLSrvr: SQLSTATE=08001, native=5. Разберем детально, что означает данный сбой, выясним его первопричины и подробно рассмотрим проверенные шаги по устранению проблемы.

Что означает код ошибки [5] и механизм Named Pipes

Проанализируем техническую сторону сообщения. Числовой код [5] (он же native=5) в системных сообщениях Windows транслируется как ERROR_ACCESS_DENIED («Отказано в доступе»). Когда клиентская библиотека SQL Server пытается подключиться к СУБД через протокол именованных каналов (Named Pipes), соединение физически устанавливается через сетевой протокол SMB (порт 445) к специальному ресурсу вида \\ServerName\pipe\sql\query.

Для открытия такого пайпа операционная система Windows обязательно выполняет сетевую аутентификацию (через Kerberos или NTLM). Если между сервером 1С и SQL Server возникают проблемы с проверкой подлинности учетных записей, правами доступа или сетевой инфраструктурой, Windows блокирует открытие канала, а драйвер Native Client возвращает ошибку с кодом 5.

Основные причины возникновения сбоя

Рассмотрим, почему работавшая ранее система может внезапно перестать устанавливать соединение:

1. Проблемы сетевой инфраструктуры и адресации. Сбои в работе DHCP-сервера, возникновение дубликатов IP-адресов в локальной сети или повреждение кэша DNS приводят к тому, что запросы уходят на некорректный узел или блокируются маршрутизаторами.
2. Рассинхронизация времени в домене. Протокол Kerberos крайне чувствителен к расхождению системных часов. Разница во времени между сервером 1С, сервером баз данных и контроллером домена более чем на 5 минут гарантированно вызывает отказ в доступе.
3. Сбои учетных записей служб или компьютера. Если служба сервера 1С запущена под локальным пользователем, а не под доменной учетной записью, при обращении к удаленному SQL Server по протоколу Named Pipes возникнет отказ. Также проблема может быть вызвана разрывом доверительных отношений компьютера с Active Directory.
4. Блокировка портов SMB. Брандмауэр Windows или стороннее антивирусное ПО могут заблокировать входящие подключения по портам TCP 139 и 445 на стороне сервера СУБД.

Способ 1. Принудительный перевод подключения на протокол TCP/IP

Самым надежным и рекомендованным решением для распределенной архитектуры (когда сервер 1С и MS SQL Server разнесены на разные машины) является отказ от именованных каналов в пользу протокола TCP/IP. Протокол TCP/IP не зависит от общих сетевых ресурсов Windows и работает быстрее и стабильнее по сети.

Разберем по шагам, как переключить базу данных на TCP/IP:

1. Откроем утилиту «Администрирование серверов 1С Предприятия».
2. Перейдем к списку информационных баз нужного кластера и откроем свойства проблемной базы данных.
3. Найдем поле «Сервер баз данных». По умолчанию там часто указано просто сетевое имя сервера (например, SQL-SRV).
4. Изменим строку подключения, явно указав протокол TCP. Для этого введем префикс tcp: перед именем сервера: tcp:SQL-SRV.
5. Если служба SQL Server использует нестандартный порт (отличный от 1433), укажем порт через запятую: tcp:SQL-SRV,1433 или используем прямой IP-адрес: tcp:192.168.1.50,1433.
6. Нажмем кнопку «ОК» или «Применить» для сохранения параметров и перезапустим сеансы пользователей.

Способ 2. Диагностика и устранение проблем в локальной сети

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

1. Проверка на конфликт IP-адресов. Проанализируем системный журнал событий Windows (System Event Log) на сервере 1С и SQL Server. Наличие записей с Event ID 4199 прямо указывает на присутствие в сети устройства с дублирующимся IP-адресом. Проверим ARP-таблицу командой: arp -a
2. Очистка кэша DNS. Если имя сервера СУБД стало разрешаться в неверный адрес, выполним сброс локального DNS-кэша в командной строке: ipconfig /flushdns
3. Проверка доступности сетевого порта СУБД. Выполним проверку доступности порта SQL Server средствами PowerShell: Test-NetConnection -ComputerName SQL-SRV -Port 1433 Успешный результат в параметре TcpTestSucceeded : True подтвердит корректную работу сетевого стека по TCP.

Способ 3. Проверка доменной аутентификации и синхронизации времени

Если специфика инфраструктуры требует использования Named Pipes, разберем действия по восстановлению доменного доступа:

1. Синхронизация времени. Проверим часы на контроллере домена, сервере 1С и SQL Server. Для ручной синхронизации времени с доменным источником выполним: w32tm /resync
2. Проверка доверительных отношений. Убедимся, что учетная запись сервера не потеряла защищенный канал с доменом. Выполним команду в PowerShell: Test-ComputerSecureChannel Если команда возвращает False, необходимо переприсоединить сервер к домену Active Directory.
3. Учетная запись службы 1С. Откроем оснастку services.msc, найдем службу Агент сервера 1С:Предприятия (ragent.exe) и проверим вкладку «Вход в систему». При работе с удаленным SQL Server по именованным каналам служба должна запускаться от доменной учетной записи, обладающей правами доступа к объектам целевого сервера.

Применение явного указания протокола tcp:ИмяСервера в свойствах базы 1С в подавляющем большинстве случаев устраняет ошибку [5] сразу, изолируя работу СУБД от временных сбоев Windows-аутентификации и сетевых пайпов SMB.