Ошибка odbc sql server driver

Обновлено: 07.07.2024

ODBC весьма полезен для процедур доступа к приложениям, особенно для профессиональных пользователей. И, похоже, существует множество проблем для пользователей Windows 10, которые либо перешли с Windows 7, либо обновили свою версию Windows 10 до последней версии.

Если вы один из них и у вас есть определенные проблемы с ODBC в Windows 10, проверьте решения ниже.

  1. Удалить SMBv1 и включить SMBv2/SMBv3)
  2. Проверьте брандмауэр Windows и Защитник Windows
  3. Обновление драйверов
  4. Откат к предыдущей версии Windows

Решение 1. Удалите SMBv1 и включите SMBv2/SMBv3)

Некоторые пользователи решили проблему, отключив SMBv1 и включив SMBv2 или SMBv3. Это можно сделать различными способами, начиная с PowerShell или редактора реестра. Последний способ быстрее и проще, но может негативно повлиять на ваш компьютер при неправильном использовании. Поэтому, прежде чем выполнять следующие шаги, обязательно сделайте резервную копию вашего реестра.

Вот как отключить SMBv1 и включить SMBv2/SMBv3:


  1. В строке поиска Windows введите regedit и откройте редактор реестра.
  2. Перейдите в ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters .
  3. Щелкните правой кнопкой мыши пустое пространство и создайте новый Dword, назовите его SMB1 и установите его значение равным 0.
  4. Щелкните правой кнопкой мыши на пустом месте и создайте новый Dword, назовите его SMB2 и установите его значение равным 1.
  5. Закройте редактор реестра и перезагрузите компьютер.

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

  • ЧИТАЙТЕ ТАКЖЕ: отключите SMBv1 в Windows с помощью этих быстрых методов

Решение 2. Проверьте брандмауэр Windows и Защитник Windows

Некоторым пользователям удалось решить проблему, просто добавив белый список или временно отключив брандмауэр Windows и включив Защитник Windows. Это долгосрочное решение, но оно того стоит. Если у вас уже есть сторонний антивирус, попробуйте объединить его с нативным антивирусом.

После этого перезагрузите компьютер и попробуйте снова получить доступ к приложению ODBC.

В случае, если вы используете 32-битный Office на 64-битной машине через ODBC, вам потребуется некоторая перенастройка, чтобы избежать ошибок драйвера. Или, скорее, доступ к версии ODBC32 вместо стандартной 64-битной версии, представленной в архитектуре x64.

Вот где его найти и как его запустить:


  1. Перейдите к C: WindowssysWOW64odbcad32.exe и запустите его. Это 32-битный администратор источника данных ODBC.
  2. Попробуйте применить драйверы снова.
  3. После того, как вы применили драйверы, перезагрузите компьютер.

Как говорили многие из затронутых пользователей, проблема возникла после того, как они обновили Windows 10 до версии 1803. То же самое можно применить к 1809. И вместо того, чтобы ждать, пока Microsoft решит проблемы ODBC в их текущем выпуске, мы скорее предлагаем откат до предыдущей версии, где сервис был полностью функциональным.

Вот как перейти к предыдущей версии Windows 10:


  1. Откройте Настройки .
  2. Выберите Обновление и безопасность .
  3. Выберите Восстановление на левой панели.
  4. Нажмите « Вернуться к предыдущей версии Windows 10 ».
  5. Нажмите Начало работы и следуйте инструкциям.

Примечание. Я явно изменил имена серверов и IP-адреса на вымышленные.

Вот что происходит. У меня есть сервер, на котором я звоню MYSERVER , под управлением Microsoft SQL Server Express 2005. Прямо на самом сервере у меня установлено соединение ODBC, указывающее на себя, и это уже отлично работает. Я вхожу в систему с использованием аутентификации SQL Server (не аутентификации Windows), и она настроена так:

Как я уже сказал, это работает. Но затем у меня есть другой компьютер, который находится в совершенно другом домене / не в интрасети, который должен получить доступ к тому же SQL-серверу, расположенному на MYSERVER. Поскольку он находится в другом домене, он не распознает имя «MYSERVER»; Я должен указать его на IP-адрес MYSERVER, который мы скажем, 123.456.789.012. Но соединение ODBC там, похоже, не работает. Я попытался настроить это так:

Это не работает Когда я ввожу имя пользователя и пароль и нажимаю «Далее», он останавливается на добрые 10–20 секунд, а затем, наконец, возвращается со следующей ошибкой:

Если я пытаюсь сделать то же самое, но изменить «сервер» с 123.456.789.012\SQLEXPRESS просто старого 123.456.789.012 , я получу другую ошибку:

Теперь я знаю, о чем ты думаешь. Вы можете подумать: «Да, вы, вероятно, не открывали брандмауэр для порта 1433, тупица». За исключением того, что я сделал, и я подтвердил это, поскольку я могу успешно запустить:

. из командной строки все, что я хочу. Так что я не уверен, что делать. Я знаю, что SQL Server существует, работает, и соединение ODBC может быть установлено правильно; Я просто не уверен, что я ошибся в настройках подключения, которые выдают эти ошибки. Исходя из последней ошибки, которую я перечислил, может показаться, что она может подключиться к серверу, но просто не может найти экземпляр (так как я не указал тот в тот раз). Так значит ли это, что мне просто нужно использовать какой-то другой синтаксис для указания IP вместе с именем экземпляра? Что я делаю? Заранее спасибо.

в ответ на совершенно простейшие запросы, MS SQL Server достаточно часто выдает очень схожие ошибки
запрос передается через SQLEXEC

MS SQL Server SP4 8.00.2039

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

сегодня это пока происходило только с двумя вьюшками, но раньше такую ошибку выдавали и другие запросы. Все 5 сегодняшних ошибки произошли у 5-ти разных пользователей на 4-х разных базах, которые размещены на одном сервере

сталкивался ли кто с подобной ошибкой и куда тут копать?

Исправлено: AlexSSS, 09.10.07 14:10

Какой-нибудь роутер глючит или коммутатор. Или маршрутизация прописана неправильная. А еще у нас админы умудрялись одно имя навешивать на два IP одновременно.


------------------
Совершенство - это не тогда, когда нельзя
ничего прибавить, а тогда, когда нечего убавить.

Исправлено: Влад Колосов, 09.10.07 15:42

проверял конкретные рабочие места - связь стабильная (смотрел графики за какое-то время). На некоторых из них стоит Scala - прога, которая очень критична к сети - у нее проблем нет

Исправлено: AlexSSS, 09.10.07 16:15

SQL очень критичен к качеству связи. Если длинные пакеты по PING не проходят - каюк связи будет.


------------------
Совершенство - это не тогда, когда нельзя
ничего прибавить, а тогда, когда нечего убавить.

К примеру, 2-4кб. Если такие пакеты пропадают, то могут быть проблемы со связью с SQL. По крайней мере, наша практика это показала.


------------------
Совершенство - это не тогда, когда нельзя
ничего прибавить, а тогда, когда нечего убавить.

проверил пинг с на 10кб на нескольких компах по несколько минут - без проблем. Сегодня поставлю мониторинг свичей, может что-то получу дополнительно
хотя врядли

что меня очень сильно смущает - проблема возникает только их двух процедур на два конкретных запроса

Исправлено: AlexSSS, 09.10.07 18:24

Сеть и свичи нормальные, у меня была ошибка связи с SQL сервером абсолютно в непредсказуемых местах. Тоже все говорили у тебя сеть глючит! Ничего и не сеть. Дело было в том, что программа обращалась к базам которые должны были лежать на локальной машине, а я их выложил на сервер и предоставил в общий доступ всем машинам.
В общем ошибка возникала из-за множественного доступа к базам, которые предусматривали работу только с одним подключением. При установке MS Server 2003 автоматом ставится НОВАЯ MS SQL Server с некоторыми настройками по умолчанию. Каждое ODBC-соединение приходится пересоздавать, если на сервере не стоит MS SQL Server 2005

1. Установи для сервера статический IP
2. На проблемных хостах пропиши в hosts статическое соответствие

Теперь смотри если ошибки пересанут сыпаться, то поднимайся на уровень выше DNS, DHCP, WINS.
Если не перестанут смотри сетевое железо, как ребята сказали.


------------------
Есть многое на свете, друг Горацио.
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет) PaulWist
1. Установи для сервера статический IP
2. На проблемных хостах пропиши в hosts статическое соответствие

1. стоит
2. сейчас соединение делается через sqlstringconnect, в котором идет обращение к DNS Alias SQL Server. Для начала попробую прописать IP сервера, а не DNS Alias

со вчерашнего вечера мониторятся все свичи, на них никаких ошибок пока нет. А с утра было уже три ошибки ;(

Посмотри внимательно в DNS-e корневые узлы (как папка верхнего уровня) всех ли их ты знаешь в лицо, нет ли там паразитных записей.


------------------
Есть многое на свете, друг Горацио.
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет) В DNS вроде все в порядке
вопрос такой. Если cоединение делается через DNS Alias, обращение к серверу идет только всегда через DNS Alias или только на момент создания соединения?
У меня создается соединение и оно одно потом используется во время всего сеанса работы программы. Работа с сервером идет только через Pass Throught AlexSSS
Если cоединение делается через DNS Alias, обращение к серверу идет только всегда через DNS Alias или только на момент создания соединения?

Наверное, только на момент создания соединения иначе бы достаточно просто было бы написать тестилку соединения, а MS вместо этого сделоло ф-ию SQLIDELDISCONNECT(), фактически разрывающую соединение, а затем вновь создающюю.


------------------
Есть многое на свете, друг Горацио.
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет) тогда DNS, скорее всего, не при чем
соединение с сервером проходит нормально, как минимум, на сервер в журнал событий пишутся события о програмной авторизации. А ошибка возникает позже, когда соединение уже установлено. И было бы вполне логично, что после того, как соединение уже установено, ODBC обращался бы к серверу через IP, а не каким-то другим способом. А обращение через IP DNS уже не затрагивает

Ну, значит вывод - где-то "физически" рвется соединение (физически в смысле пакеты не доходят до сервака и обратно) в момент выполнения запроса.


------------------
Есть многое на свете, друг Горацио.
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

С приоритетами сервера не игрались?


------------------
Совершенство - это не тогда, когда нельзя
ничего прибавить, а тогда, когда нечего убавить.

проверил, используется ли DNS, когда соединение уже установлено

1. создал DNS Alias = SqlServer
2. Ping DNS Alias - OK
3. sqlconnect with - DNS Alias - OK
4. Удаляю DNS Alias
5. на компе ipconfig /flushdns
6. Ping DNS Alias - не проходит
7. SQLGETPROP(m.handle,"ConnectString" ) - соединение через DNS Alias
8. Программа корректно работает, хотя DNS Alias уже не существует

Вывод - DNS может использоваться только при создании соединения (а может и не использоваться, если. напр. указан IP сервера). При уже созданном соединении он не используется

Кроме того, DNS-овские соединения кэшируются на самой локальной машине. И если dns-овское имя закэшировано на локальном компе, то при sqlstringconnect обращения к DNS серверу не происходит. Проверено. На DNS сервере DNS Alias уже удален, но на локальном компе он еще пингуется за счет локального кэша. И sqlstringconnect соединяется с сервером без всяких проблем

База 1С SQL. Подключается 5 ПК. На одном из них переустановили систему, установили платформу 7.7, при попытке подключения к базе выдает ошибку:

SQL State:08001
Native:17
Messeg:[Microsoft][ODBC SQL Server Driver][DBNetLib] SQL Server не существует или отсутствует доступ.
SQL State:01000
Native:2
Messeg:[Microsoft][ODBC SQL Server Driver][DBNetLib] Connection open(Connect())

Причин возникновения проблем с подключением к SQL Server-у может быть много, но есть простые методы диагностики и выявления проблем подключения к серверу.

Шаг 1.
Попробуйте «пропинговать» сервер БД как по имени так и по IP-адресу, командой
Ping [SQLServerDNSName], где SQLServerDNSName – DNS имя сервера БД в сети. Если возникли проблемы с пингом по имени, то необходимо устранить проблемы со службой DNS в Вашей сети. Если сервер не пингуется по IP-адресу, то необходимо решить проблемы, либо с маршрутизацией пакетов в сети, или проверить саму сеть на наличие физических обрывов.

Шаг 2.
Выполняется при условии, что шаг 1 выполнился успешно.
Простая проверка к соединения с сервером БД осуществляется командой
telnet [SQLServerIPAdress] [port] – где SQLServerIPAdress IP-адрес сервера, port-порт подключения к серверу, по умолчанию 1433. При удачном подключении, экран терминала telnet будет чистым с мигающим курсором. При неудачном подключении необходимо проверить порт подключения к серверу. Определение настроек порта на клиенте выполняется утилитой cliconfg.exe, на сервере - утилитой svrnetcn.exe.

Шаг 3.
Выполняется при условии, что шаги 1 и 2 выполнились успешно.
Часто на этом шаге при подключении возникает ошибка «Login failed for user [UserName]», где UserName-имя пользователя, под которым вы хотите подключиться к серверу БД. При возникновении такой ошибки необходимо проверить тип авторизации. По умолчанию при установке SQL Server-а разрешена только Windows авторизация. Если Вы подключаетесь под логином sa, то Вам необходимо установить на сервере БД смешанную(mixed) авторизацию. Также необходимо проверить пароль для логина, под которым Вы подключаетесь.

Читайте также: