#sql-server
Вопрос:
Предоставьте Используемый: Поставщик Microsoft OLE DB для SQL Server. Кто-нибудь может мне в этом помочь.. Я пытался связаться с LLBLGen
Ответ №1:
На этой странице блога MSDN есть кое-что полезное по этому поводу…
Ответ №2:
В моем случае я обнаружил, что учетная запись заблокирована. Причиной было то, что я ранее на другой машине более 3 раз пытался войти в систему. Он не узнал меня — и тогда, наконец, заблокировал мою учетную запись.
При повторном открытии учетной записи все работало нормально.
бр Ян
Ответ №3:
Ошибка, которую вы получаете, почти всегда вызвана проблемой с использованием проверки подлинности Windows. Пожалуйста, попробуйте переключиться на имя пользователя SQL server (имя пользователя/пароль) или убедитесь, что ваш текущий логин Windows имеет доступ к серверу SQL и базе данных, к которым вы пытаетесь подключиться.
-Эдуде
Ответ №4:
Я исправил это, сопоставив диск с сервером, на котором работает MSSQL. Это, казалось, создало какое-то доверие, которое позволяет MSSQL подключаться без этой ошибки даже после перезагрузки.
Ответ №5:
Я иногда получал эту ошибку при подключении к локальному SQL-серверу с проверкой подлинности Windows. К сожалению, я так и не исправил его — он исчез, когда я переустановил Windows.
Я думаю, что перезагрузка исправляла это — вы пробовали это сделать? Не совсем лучшее решение, я знаю 😛
Комментарии:
1. Ни перезагрузка, ни переустановка SQL server не решат эту проблему.
2. Перезагрузка решила эту проблему и для меня — навсегда. У меня эта ошибка появилась на виртуальной машине, подключенной к корпоративному домену через VPN-клиент Citrix. Перезагрузка виртуальной машины сама по себе не разрешила эту проблему. Мне пришлось перезагрузить хост. Я также не смог подключиться ни к каким общим ресурсам Windows, пока у меня была эта проблема. Но я явно был в домене, мог подключаться по протоколу RDP к серверам и получать доступ к интрасети в IE.
Ответ №6:
Попробуйте синхронизировать свою дату и время с датой и временем вашего домена. Проблема SSPI может быть связана с проблемами проверки подлинности Active Directory, некоторые из которых связаны с изменениями даты и времени. Это очень просто проверить и исправить. Попробуйте это сделать!
Ответ №7:
Существует статья Microsoft KB, в которой рассматриваются многие причины этой области (KB811889) по следующему адресу: http://support.microsoft.com/kb/811889.
Множество поисковых запросов показывает, что один из диагностических шагов помог большинству людей, столкнувшихся с этой проблемой.
Недавно у меня была именно такая проблема, когда я получал эту ошибку только при аутентификации с определенными учетными записями, но не с другими. В конечном счете, причина моей проблемы не была упомянута ни в одном КБ или статье, которые я нашел в сети, но методом проб и ошибок я обнаружил, что, когда учетная запись, используемая для аутентификации SSPI на SQL Server (2k8), оказалась в большом количестве групп (в моем случае более 250), вы получите ошибку «Не удается создать контекст SSPI». Я подозреваю, что это как-то связано с переполнением маркера безопасности, который использует Kerberos, и наблюдал аналогичные странные проблемы с аутентификацией для учетных записей пользователей в большом количестве групп.
Ответ №8:
У меня возникает проблема, когда на моем клиентском компьютере время установлено иначе, чем на сервере или на рекламном компьютере ( я пытался протестировать его в будущем).
Ответ №9:
Короткий ответ: Вы недавно сменили пользователя, от имени которого работает служба? Произошел ли сбой в системе?
Длинный ответ: Я знаю, что это устарело, но я хочу опубликовать свой опыт, который у меня только что был. Мы потратили несколько часов на поиск в Гугле и не нашли ничего, что работало бы. В конце концов мы столкнулись с рядом действий, которые могли привести к этому:
Если вы измените пользователя, под которым работает Sql Server (например, из локальной системы в usr домена), и выполните определенные обновления, а сервер не перезагрузится безопасно, вы получите это.
Итак, мы вернули все в Локальную систему, и все сработало. Поменял его на пользователя домена, без проблем. Хорошо. Переключил его в локальную систему, перезагрузил, переключил на пользователя домена, перезагрузил, бам — работяга, работяга. В нашем мире все было хорошо. Позже в то утро он снова обосрался… все еще работаю над этим сейчас, но приоритет меняется, и я не уверен, что мы продолжим работу над этой проблемой, поэтому я хотел опубликовать что-нибудь на случай, если это случится с кем-то еще.
Причиной нашего было то, что мы сделали обновление, и, по-видимому, мы узнали, что это плохая практика, разрешать Sql Server работать как локальная система, поэтому мы изменили его на пользователя домена. Мы никогда не перезагружались, но перезапустили службу. Через месяц мы делаем обновления. Мы не перезагружаемся. Проходит месяц, и полоска питания поджаривается, что приводит к неожиданному отключению сервера. Еще через месяц мы обнаруживаем проблему, потому что мы редко подключаемся к этой конкретной базе данных (интересно, что Sql Server 2008 работал нормально… это было только в 2005 году). Или… по крайней мере, это лучшее, с чем мы сталкивались.
Наш администратор не любит Vista и любит сваливать все на Vista (отказывается разрешить нам протестировать Windows 7)… поэтому он погуглил «sspi vista» или что-то в этом роде (я знаю, что у него были sspi и vista, но, возможно, у него была другая… на случай, если вам нужно будет Погуглить, это было хорошо), и наткнулся на статью, которая довольно подробно объяснила наш сценарий после того, как мы встретились, мы все помним эти фрагменты и поместили эту фотографию вместе.
Ответ №10:
В моем случае проблема синхронизации времени в доменной среде Windows 2003 на самом деле была проблемой.
Это было довольно легко не заметить, так как эти двое находились в двух разных часовых поясах, показывая одно и то же время на своих часах; что, по сути, было примерно в 1 часе друг от друга.
Так что, кроме времени на их часах, проверьте также часовые пояса.