Sql error что это
@@ERROR (Transact-SQL)
Возвращает номер ошибки для последней выполненной инструкции Transact-SQL.
Синтаксические обозначения в Transact-SQL
Синтаксис
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Типы возвращаемых данных
Примечания
Возвращает 0, если в предыдущей инструкции Transact-SQL не возникло ошибок.
Возвращает номер ошибки, если в предыдущей инструкции возникла ошибка. Если ошибка относится к представлению каталога sys.messages, @@ERROR содержит значение столбца sys.messages.message_id для этой ошибки. Текст, связанный с номером ошибки @@ERROR, можно просмотреть в sys.messages.
Так как функция @@ERROR очищается и сбрасывается для каждой выполняемой инструкции, проверяйте ее сразу после инструкции или сохраните значение в локальной переменной для последующей проверки.
Для обработки ошибок используйте конструкцию TRY. CATCH. Конструкция TRY. CATCH также поддерживает дополнительные системные функции (ERROR_LINE, ERROR_MESSAGE, ERROR_PROCEDURE, ERROR_SEVERITY и ERROR_STATE), возвращающие более подробные сведения, чем @@ERROR. Кроме того, TRY. CATCH поддерживает функцию ERROR_NUMBER, которая не ограничена тем, что возвращает номер ошибки немедленно после выполнения инструкции. Дополнительные сведения см. в разделе TRY. CATCH (Transact-SQL).
Примеры
A. Использование функции @@ERROR для обнаружения конкретной ошибки
Б. Использование функции @@ERROR для выхода из процедуры по условию
В приведенном ниже примере инструкции IF. ELSE выполняют проверку @@ERROR после инструкции DELETE в хранимой процедуре. Значение переменной @@ERROR определяет код возврата, который отправляется вызывающей программе и указывает на успешное или неуспешное выполнение процедуры.
В. Использование @@ERROR с @@ROWCOUNT
MS SQL 2011 — Обработка ошибок
Это слово может использоваться в сочетании с управляющей конструкцией Try…Catch и позволяет послать уведомление о возникновении ошибки времени исполнения. Когда возникает исключение, программа ищет ближайший по иерархии вверх блок Catch который может обработать исключение. Используя это выражение внутри блока Catch можно изменить вывод ошибки. Более того, теперь вызывать исключение можно произвольно в любом месте скрипта.
Далее рассмотрим различные способы поимки исключении, которые предоставляет SQL Server начиная с версии 2000 и до версии 2011, с указанием плюсов и минусов.
Для всех рассматриваемых случаев будет использоваться таблица tbl_ExceptionTest.
Для того, чтобы не протыкивать дизайнер мышью, можно выполнить следующий скрипт для создания искомой таблицы (сгенерировано автоматически).
Далее будем пытаться добавить в таблицу несколько записей и при внесении неподходящих данных в колонку Phone Number генерировать исключения.
Обработка ошибок в SQL Server 2000 (Sphinx)
Использование глобальной переменной @@ERROR
Возвращаясь во времена использования SQL Server 2000, вспоминаем что использование переменной @@Error было на тот момент самым прогрессивным и эффективным способом обработки ошибок. Данная переменная отвечала за возврат целочисленного значения ошибки, которое произошло в последнем выполненном выражении. Значение ошибки могло быть как положительным, так и отрицательным, лишь 0 указывал на успешность выполнения операции. Значение переменной менялось после каждого выполненного выражения.
Посмотрим на использование @@Error в действии.
Общий смысл скрипта сводиться к тому, что в последней записи мы намеренно вызываем ошибку и читаем ее значение из локальной переменной. Если значение ошибки не равно нулю, то показываем осмысленное предупреждение пользователю. Если ошибок нет, то сохраняем результаты.
Выполнение данного скрипта приведет к появлению ошибки, как показано ниже
Msg 515, Level 16, State 2, Line 26 Cannot insert the value NULL into column ‘Phone Number’, table ‘tempdb.dbo.#tblExceptionTest_____000000000023’; column does not allow nulls. INSERT fails. The statement has been terminated. Msg 50000, Level 16, State 1, Line 43 Attempt to insert null value in [Phone Number] is not allowed
Естественно, что вся транзакция откатится назад и ничего не будет внесено в таблицу.
Недостатки подхода с использованием @@Error
Использование глобальной переменной @@TRANCOUNT
Эта переменная возвращает количество транзакций выполняющихся в момент обращения к переменной. Из описания уже понятно, что она постоянна примерно в той же мере, что и @@ERROR, т.е. постоянно меняется во время исполнения транзакций. Это опять подводит нас к тому, чтобы использовать локальные переменные для хранения значений в интересующий момент времени.
Каждый вызов BEGIN TRANSACTION увеличивает значение @@TRANCOUNT на 1 и каждый вызов COMMIT TRANSACTION уменьшает ее значение на 1. ROLLBACK TRANSACTION не изменяет значения @@TRANCOUNT. Записи считаются внесенными только когда значение @@TRANCOUNT достигнет 0.
Рассмотрим использование @@TRANCOUNT на следующем примере.
В данном скрипте мы опираемся на количество закрытых транзакций. Транзакции могут быть вложенные, так что такой способ имеет право на существование.
Для получения дополнительной информации по @@TRANCOUNT обратитесь на MSDN.
Использование глобальной переменной @@ROWCOUNT
Данная переменная возвращает количество измененных строк в результате выполнения запроса/команды.
Поведение такое же, как и у предыдущих двух, так что сохраняем промежуточные результаты в локальную переменную для последующего анализа.
В данном случае мы ожидаем, что вставится одна запись в таблицу, но если количество вставленных записей равно нулю, то явно что-то не в порядке.
Для того, чтобы получить больше деталей по использованию @@ROWCOUNT читайте MSDN.
Обработка ошибок в SQL Server 2005/2008 (Yukon/Katmai)
После вывода на рынок SQL Server 2005 и развития его идей в SQL Server 2008 у разработчиков на TSql появился новый блок Try…Catch. Теперь стало возможно перехватывать исключения без потери транзакционного контекста.
Пример на использование блока Try … Catch.
В примере больше не используется вспомогательных переменных для определения ошибки выполнения скрипта по косвенным признакам.
После запуска скрипта получим сообщение следующего вида:
Msg 50000, Level 16, State 1, Line 45 Attempt to insert null value in [Phone Number] is not allowed
Как вы уже наверно заметили, на этот раз вывелось только то, что было задано в сообщении об ошибке. Никаких дополнительных, смущающих пользователя сообщений, SQL Server не показал. Выполняемый код обрамлен в блоке try и обработка ошибки в блоке catch. Получается чистый и ясный для понимания код. Если весь желаемый код прошел без ошибок, то код из блока Catch не будет вызван.
Теперь мы получим такой ответ от сервера:
Недостатки использования функции RaiseError
1 Если вспомнить, что показывала эта функция вызванная в Catch блоке, то заметим, что она ссылалась на строку номер 45, как источник проблем.
Однако в действительности ошибка произошла в строке номер 24, так где было написано
Insert into #tblExceptionTest([Phone Number]) Values(null)
В то время как функция ERROR_LINE() возвращает всегда реальное место возникновения ошибки. Еще один способ, чтобы показать работу новых функций будет такой:
В этом случае движок SQL Server выдаст такое сообщение:
Из чего можно заключить, что использование RaiseError не дает возможности указать на реальное место в скрипте, где произошла исключительная ситуация.
2 Следующий недостаток функции RaiseError состоит в том, что нет возможности повторно инициировать тоже самое исключение, для передачи вверх по иерархии вызовов. Так, если переписать блок Catch как показано ниже
То полученное сообщение об ошибке будет таким:
Msg 2732, Level 16, State 1, Line 46 Error number 515 is invalid. The number must be from 13000 through 2147483647 and it cannot be 50000
Причной этого является то, что для инициирования нового сообщения об ошибке, номер ошибки должен содержаться в таблице sys.messages.
Обработка ошибок в SQL Server 2011 (Denali)
Упомянутые выше недостатки функции RaiseError могут быть успешно преодолены с помощью новой команды Throw.
Первый недостаток функции RaiseError, на который мы указали ранее, невозможность сослаться на точную строку возникновения ошибки. Рассмотрим насколько далеко от места возникновения ошибки мы оказываемся при использовании команды Throw.
Перепишем блок Catch с использованием команды Throw.
Это точно то место, где произошла ошибка. Что ж, работает пока на отлично.
Вторым недостатком было то, что функция RaiseError не может повторно инициировать исключение потому, что RAISE ERROR ожидает номер ошибки, который хранится в таблице sys.messages. Команда Throw не ожидает, что номер ошибки должен быть из диапазона системной таблицы sys.messages, однако номер можно задать из диапазона от 50000 до 2147483647 включительно.
Снова изменим блок Catch в соответствии с новыми знаниями.
Результатом возникновения исключения будет
Msg 50001, Level 16, State 1, Line 45 Attempt to insert null value in [Phone Number] is not allowed
Получим сообщение об ошибке следующего плана:
Msg 208, Level 16, State 0, Line 3 Invalid object name ‘tblInvalid’.
Получается что почти невозможно перехватить такие типы ошибок.
Но. Как всегда есть небольшой трюк как осуществить желаемое. Основная идея в том, чтобы сделать две хранимых процедуры и вызывать одну из другой в блоке Try…Catch и ловить исключение. Для доказательства нашего предположения используем для экспериментов следующий скрипт.
При запуске процедуры ExternalStoredProc получим сообщение:
И панель Result отобразит следующие данные:
Что нам и требовалось!
Теперь немного объяснений как работает код. У нас есть 2 хранимых процедуры: usp_InternalStoredProc и usp_ExternalStoredProc. В usp_InternalStoredProc мы пытаемся вставить запись в несуществующую таблицу #tblInnerTempTable, в результате чего получаем исключительную ситуацию, которая в свою очередь отлавливается внешним блоком Catch, расположенным во внешней процедуре.
Более того, строка и текст ошибки полностью соответствуют нашим ожиданиям и указывают на точное место.
Очень важно не забыть закрыть точкой с запятой предстоящее перед THROW выражение во внешней процедуре. THROW должен быть новым набором команд. В противном случае получите ошибку
Incorrect syntax near ‘THROW’.
Больше детальной информации о THROW можно подчерпнуть из MSDN.
Устранение ошибок подключения к SQL Server
В этой статье вы сможете решить различные проблемы с подключением SQL сервера.
Подробнее об опыте этой статьи см. в статье Solving Connectivity errors to SQL Server.
Оригинальная версия продукта: Microsoft SQL Server
Исходный номер КБ: 4009936
Предварительное условие
Для эффективного использования этого устранения неполадок может потребоваться собрать следующую информацию.
Полный текст сообщения об ошибке, а также коды ошибок и периодические ошибки (случается только иногда) или последовательно (происходит все время).
Ошибки из SQL Server, из которых можно отметить следующее:
Полное доменное имя (FQDN) компьютера SQL Server или в случае кластерных установок виртуальное имя FQDN. Если используется экземпляр с именем, обратите внимание на имя экземпляра.
Вы можете найти строку «Имя сервера», чтобы получить эту информацию в ошибке.
Сетевые библиотеки и порты SQL, в который прослушивается экземпляр. Примеры сообщений:
Именуемые трубы. Локальный поставщик подключений Server готов принять подключение к \ \ [\pipe\sql\query]. TCP/IP и номер порта: сервер прослушивает [::1 1433].
Журналы событий приложений и систем из SQL Server и клиентских систем.
При сбое подключений из приложения строка подключения из приложения. Они обычно находятся в Web.config для ASP.NET приложений.
Контрольный список
Убедитесь SQL что сервер запущен, и вы увидите следующее сообщение в SQL Server ErrorLog:
SQL Server теперь готова для клиентских подключений. Это информационное сообщение; никаких действий пользователя не требуется.
Проверьте, SQL ли он прослушивает соответствующие протоколы, просмотрев ErrorLog.
Проверьте, можно ли подключиться к SQL серверу с помощью UDL-файла. Если он работает, может возникнуть проблема со строкой подключения. Инструкции по процедуре о тесте UDL переходить Подключение на SQL сервер с помощью раздела файлов UDL.
Проверьте, можно ли подключиться к SQL Server из других клиентских систем и различных логинов пользователей. Если вы в состоянии, то проблема может быть спецификой для клиента или входа, который испытывает проблему. Проверьте журналы Windows событий в проблемном клиенте для получения дополнительных указателей. Кроме того, проверьте, устарели ли драйверы сети.
При сбоях входа убедитесь, что пользователь имеет вход на уровне сервера и соответствующие разрешения для подключения к базе данных, к которой пользователь пытается подключиться.
При создании подключения к SQL Server
Дополнительные сведения о соответствующей ошибке см. в следующем разделе Проверка ошибок подключения.
Проверка ошибок подключения
Ошибка, связанная с сетью или конкретным экземпляром, произошла при создании подключения к SQL Server представляет одно или несколько следующих сообщений об ошибке:
При создании подключения к SQL Server произошла ошибка, связанная с сетью или конкретным экземпляром. Сервер не был найден или недоступен. Убедитесь, что имя экземпляра правильно и SQL Server настраивается для допуска удаленных подключений.
SQL Server Native Client ссылки данных
[Microsoft SQL Server Native Client 10.0]: Login timeout expired
[Microsoft SQL Server Native Client 10.0]: A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.
[Microsoft SQL Server Native Client 10.0]: SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].
При создании подключения к SQL Server произошла ошибка, связанная с сетью или конкретным экземпляром. Сервер не был найден или недоступен. Убедитесь, что имя экземпляра правильно и SQL Server настраивается для допуска удаленных подключений.
поставщик: поставщик TCP, ошибка: 0
Попытка подключения не удалась из-за того, что подключенная сторона не отвечала должным образом после определенного периода времени, или не удалось установить подключение, так как подключенный хост не справился с ответом.
Microsoft SQL Server, ошибка: 10060
При создании подключения к SQL Server произошла ошибка, связанная с сетью или конкретным экземпляром. Сервер не был найден или недоступен. Убедитесь, что имя экземпляра правильно и SQL Server настраивается для допуска удаленных подключений.
поставщик: Названный поставщик труб, ошибка:40 — не удалось открыть подключение к SQL Server
Microsoft SQL Server, ошибка:53
Путь сети не найден
[Microsoft] [SQL Server Native Client 11.0]Поставщик TCP: Подключение не удалось сделать, так как целевая машина активно отказалась от него.
[Microsoft] [SQL Server Native Client 11.0]Истек срок действия времени входа
[Microsoft] [SQL Server Native Client 11.0]При создании подключения к SQL Server произошла ошибка, связанная с сетью или экземпляром. Сервер не найден или недоступен. Проверьте, правильно ли имя экземпляра и SQL Server настроены для допуска удаленных подключений. Дополнительные сведения см. в SQL Server Books Online.
Вы можете начать устранение неполадок из этого раздела: Общие причины различных проблем с подключением.
Общие причины различных проблем с подключением
Пройдите по каждой из причин, применимых к вашему экземпляру ниже и для каждой из применимых причин, попробуйте соответствующие разрешения.
Причина 1. Неправильное имя сервера, указанное в строке подключения или в диалоговом окне имя сервера
Убедитесь, что имя сервера, которое указывает приложение, соответствует тому, что имеется в журнале ошибок.
Перейдите к файлу ASP.NET Configuration Files для приложения и убедитесь, что раздел Строки подключения указывают на правильное имя сервера и использует соответствующие SQL Server строки подключения для ASP.NET веб-приложений.
Чтобы программным образом получить строки подключения из приложения, обратитесь к примеру в раздел How to: Read Connection Strings from the Web.config File.
Причина 2. Неправильный псевдоним на клиентской машине
Псевдонимы обычно используются в средах, когда необходимо подключиться к SQL Server с альтернативным именем или при проблемах с разрешением имен в сети. Неправильный псевдоним на клиентской машине может привести к тому, что подключения из приложений перейдут на неправильный сервер, что приведет к сбою.
Что нужно попробовать:
Откройте SQL Server клиентскую сеть, введяcliconfg.exe в команде Run.
Проверьте, есть ли псевдонимы, определенные для сервера, к который вы пытаетесь подключиться.
Если есть, сделайте следующее:
Нажмите кнопку Изменить и переименовать псевдоним Server. (например, если имя сервера — MySQL, переименуйте его в MySQL_test) и повторное подключение. Если подключение работает, это указывает на то, что у вас был неправильный псевдоним, вероятно, из старой конфигурации, которая больше не требуется. Если вы продолжаете испытывать ошибку, переименуем псевдоним обратно в его первоначальное имя и переступим к следующему шагу.
Проверьте параметры Подключения для псевдонима и убедитесь, что они правильные. Некоторые из распространенных сценариев, которые могут вызвать проблемы с подключением:
Неправильный IP-адрес для параметра Имя сервера. Убедитесь, что этот IP-адрес соответствует записи в файле SQL ErrorLog.
Неправильное имя сервера в параметре Имя сервера. Например, если псевдоним Server указывает правильное имя сервера, если параметр имя сервера имеет неправильное значение, подключения сбой.
Если вы используете псевдоним с именем pipes, убедитесь, что имя трубки имеет правильный формат.
Причина 3 (экземпляр по умолчанию): брандмауэр (s) между клиентом и сервером, блокирующий порт, SQL Server экземпляр прослушивается
Экземпляр по умолчанию. Экземпляр по умолчанию обычно выполняется в порту 1433. Некоторые установки также используют нестандартный порт (кроме 1433) для SQL экземпляров. Брандмауэр может блокировать любой из них.
Что нужно попробовать:
Определите номер порта, SQL экземпляр запущен. Если экземпляр SQL сервера по умолчанию использует нестандартный порт, см. в примере Running SQL Server ‘Default’в порту TCP по умолчанию (или нестандартным): советы по подключению приложений.
Попробуйте примкнутый номер порта SQL Server имя сервера с помощью формата , portnumber и посмотреть, если это работает. Например, если ваше имя SQL является MySQLDefaultinstance и оно запущено в порту 2000, укажите имя сервера как MySQLServer, 2000 и узнайте, работает ли это. Если он работает, это указывает на то, что брандмауэр блокирует порт.
В случае подтверждения добавьте порт в список исключений Брандмауэра. Для инструкций переходить к разделу Настройка брандмауэров.
Причина 4 (Экземпляр с именем): SQL браузер не запущен
Клиентские приложения, подключающиеся к именитому экземпляру SQL Server, используют службу браузера SQL в системе, в которой SQL работает, чтобы SQL прослушивается. Если служба браузера не запущена, подключения сбой.
Что нужно попробовать:
В системе, SQL Server экземпляре, используйте диспетчер конфигурации SQL Server или applet Services в панели управления и запустите службу SQL браузера, если она еще не запущена. Дополнительные сведения см. в фото: Start and Stop the SQL Server Browser Service
Причина 5 (Названный экземпляр): UDP Port 1434, используемый SQL браузер заблокирован в сети
Если экземпляр SQL является именем экземпляра, он может быть настроен на использование динамических портов или статический порт. В любом случае, в основе запроса сетевых библиотек SQL служба браузера, запущенная на SQL Server компьютере через порт UDP 1434, чтобы скомпромитировать номер порта для именуемого экземпляра. Если брандмауэр между клиентом и сервером блокирует этот порт UDP, клиентская библиотека не может определить порт (требование для подключения) и подключение не удается.
Метод 1:
Метод 2:
Что нужно попробовать:
Сначала определите, прослушивается ли SQL Server динамический и статичный порт, и используйте процедуру, соответствующую вашему сценарию. Как узнать, прослушивается ли SQL динамических и статических портах, переходить к разделу «Скажите, SQL ли вы слушаете в разделе Динамические и Статические порты».
Пример 1. Динамические порты. В этом случае необходимо убедиться SQL служба браузера действительно запущена и порт UDP 1434 не заблокирован на брандмауэре между клиентом и сервером. Если вы не можете сделать ни один из них, следует переключить экземпляр SQL Server для использования статического порта и использовать процедуру, задокументированную в Настройка сервера для прослушивания в конкретном TCP-порте.
Пример 2. Статическая конфигурация порта и SQL браузера не запущены или UDP 1434 не может быть открыт на брандмауэре. В этом случае необходимо убедиться, что статичный порт указан в строке подключения и порт не блокируется брандмауэром. Для инструкций переходить к разделу Настройка брандмауэров.
Если это не решает проблему, переехав в раздел «Все еще возникают проблемы».
Настройка брандмауэров
Если вы используете брандмауэр Windows, используйте процедуру, описанную в разделе SQL Server Книги Online:
Если используется настраиваемый брандмауэр, работайте с сетевым администратором, чтобы открыть необходимые порты.
Ниже приведены некоторые быстрые скриншоты, показывающие необходимую конфигурацию брандмауэра Windows для успешного подключения к экземпляру по умолчанию и названного экземпляра.
Экземпляр по умолчанию SQL Server в порту по умолчанию 1433 на Windows R2 2012. В этом сценарии необходимо убедиться, что в TCP-порт 1433 в брандмауэре TCP Windows исключение.
Откройте Windows брандмауэр в экземпляре по умолчанию SQL сервера и нажмите кнопку New Rule under Inbound Rules.
Выберите параметр Порт и нажмите кнопку Далее.
На следующем экране:
Выберите TCP в качестве протокола.
Выберите конкретные локальные порты и укажите значение 1433 и нажмите кнопку Далее.
На следующем экране выберите Разрешить подключение и нажмите кнопку Далее.
На следующем экране выберите параметр, который лучше всего подходит для вашей среды, и нажмите кнопку Далее.
На следующем экране дайте имя правилу и уканите четкое описание будущей ссылки и нажмите кнопку Готово.
После этого вы должны увидеть, что правило создано и включено по умолчанию.
Добавление исключения для порта UDP 1434 для подключения к имениму экземпляру SQL сервера:
Откройте Windows брандмауэр в экземпляре по умолчанию SQL сервера и нажмите кнопку New Rule under Inbound Rules.
Выберите параметр Порт и нажмите кнопку Далее.
На следующем экране:
Выберите UDP в качестве протокола.
Выберите локальные порты и укажите значение 1434 и нажмите кнопку Далее.
На следующем экране выберите Разрешить подключение и нажмите кнопку Далее.
На следующем экране выберите параметр, который лучше всего подходит для вашей среды, и нажмите кнопку Далее.
На следующем экране дайте имя правилу и уканите четкое описание будущей ссылки и нажмите кнопку Готово.
После этого вы должны увидеть, что правило создано и включено по умолчанию.
Если это не решает проблему, переехав в раздел «Все еще возникают проблемы».
Использование средства PortqryUI с SQL Server
Экземпляр по умолчанию в порту по умолчанию: рабочий сценарий
Экземпляр по умолчанию в порту по умолчанию: сценарий нерабояния
Пример с именем: Рабочий сценарий: (Имя экземпляра: SQL 2014 г., имя хозяйского пользователя: SQLCONNVM)
Дополнительные сведения переходить к разделу Настройка брандмауэров.
Если это не решает проблему, переехав в раздел «Все еще возникают проблемы».
Скажите, SQL прослушивает динамические и статические порты
В диспетчер конфигурации SQL Server области консоли разместим SQL Server конфигурации сети, разместим протоколы для, а затем дважды щелкните TCP/IP.
В диалоговом окне TCP/IP Properties на вкладке IP-адресов несколько IP-адресов отображаются в формате IP1, IP2, до IPAll. Один из них — IP-адрес адаптер 127.0.0.1. Для каждого IP-адреса на компьютере отображаются дополнительные IP-адреса. (Вероятно, вы увидите IP-адреса версии 4 и IP-версии 6.) Щелкните правой кнопкой мыши каждый адрес и нажмите кнопку Свойства, чтобы определить IP-адрес, который необходимо настроить.
Если диалоговое окно TCP Dynamic Ports содержит 0, это указывает на то, что ядро СУБД прослушивается в динамических портах. Если он содержит определенный номер, это означает, что экземпляр базы данных прослушивается в статическом порту.
Дополнительные сведения см. в веб-сайте Настройка сервера для прослушивания в определенном порту TCP.
Если это не решает проблему, переехав в раздел «Все еще возникают проблемы».
Подключение не удалось сделать, так как целевая машина активно отказалась от него
Дополнительные сведения об ошибке без подключения переходить в раздел Полное сообщение об ошибке.
Полное сообщение об ошибке
Вы можете получить ошибку, аналогичную следующему:
[Microsoft] [SQL Server Native Client 11.0]Поставщик TCP: Подключение не удалось сделать, так как целевая машина активно отказалась от него.
[Microsoft] [SQL Server Native Client 11.0] истек срок действия времени входа.
[Microsoft] [SQL Server Native Client 11.0]При создании подключения к SQL Server произошла ошибка, связанная с сетью или экземпляром. Сервер не найден или недоступен. Проверьте, правильно ли имя экземпляра и SQL Server настроены для допуска удаленных подключений. Дополнительные сведения см. в SQL Server Books Online.
Вы можете начать устранение неполадок из этого раздела: Общие причины различных проблем с подключением.
SQL Server не существует или доступа не отказано
Вы можете начать устранение неполадок из этого раздела: Общие причины различных проблем с подключением.
Сбой операции pivotTable: мы не можем найти сервер для загрузки модели данных книг
Вы можете начать устранение неполадок из этого раздела: Общие причины различных проблем с подключением.
Невозможно создать сообщение об ошибке контекста SSPI
Интерфейс поставщика службы безопасности (SSPI) — это набор API Windows, который позволяет делегировать и взаимную проверку подлинности на любом общем уровне транспорта данных, например в розетках TCP/IP. Поэтому SSPI позволяет компьютеру с операционной системой Windows безопасно делегировать маркер безопасности пользователя с одного компьютера на другой через любой транспортный уровень, который может передавать необработанные bytes данных.
Ошибка контекста Cannot создается, когда SSPI использует проверку подлинности Kerberos для делегирования проверки подлинности TCP/IP и Kerberos не может завершить необходимые операции для успешного делегирования маркера безопасности пользователя на запущенный SQL Server.
Дополнительные сведения о том, почему операции Kerberos невозможно завершить, переходить к устранению сбоев проверки подлинности из-за проблем Kerberos для проверки и реализации действий.
Устранение сбоев проверки подлинности из-за проблем Kerberos
Сбои проверки подлинности Kerberos могут происходить по разным причинам. Основные причины и соответствующие решения приведены ниже:
Когда начинается экземпляр SQL Server ядро СУБД, SQL Server пытается зарегистрировать SPN для SQL Server службы. Когда экземпляр остановлен, SQL Server пытается оторегистрить SPN. Для этого для SQL учетной записи службы в активном каталоге необходимы права ReadServicePrincipalName и WriteServicePrincipalName. Но если учетная запись службы не имеет этих прав, автоматической регистрации SPN не происходит, и вам необходимо работать с администратором Active Directory, чтобы зарегистрировать их для экземпляров SQL, чтобы включить проверку подлинности Kerberos. В этом сценарии, если используется экземпляр с именем, будет удобнее использовать статичный порт для этого экземпляра. При использовании динамических портов номер порта может изменяться при каждом перезапуске службы, а зарегистрированный вручную SPN для экземпляра перестает быть допустимым. Дополнительные сведения см. в рублях Регистрация основного имени службы для подключений Kerberos.
В средах, в которых SQL кластерная автоматическая регистрация СНО не рекомендуется, так как для регистрации SPN и R-регистрации spN в Active directory может потребоваться больше времени, чем для SQL, чтобы выйти в интернет. Если регистрация SPN не произойдет вовремя, это может SQL в Интернете, так как администратор кластера не может подключиться к SQL серверу.
Использование диспетчера конфигурации Kerberos для диагностики и устранения проблем spN и делегирования
Запустите средство с помощью учетной записи домена предпочтительно с учетной записью, которая обладает достаточными привилегиями для создания SPNs в вашем активном каталоге. См. ниже рисунок:
Подключение SQL Server вы хотите собрать сведения об ошибках Kerberos:
После подключения можно увидеть различные вкладки, как показано ниже:
System: Имеет базовую информацию о системе.
SPN: Предоставляет spN-сведения о экземплярах каждого экземпляра SQL, найденных на целевом сервере, и предоставляет различные варианты, как отмечено ниже. С помощью этой вкладки можно найти отсутствующие или неправильно сконфигуративные spNs и кнопки «Создание» или «Исправление», чтобы устранить эти проблемы.
Параметр Generate позволит создать скрипт поколения SPN. Щелкнув кнопку «Создание», выключите следующий диалог:
Этот параметр создает командный файл, который можно выполнять из командного запроса для создания SPN.
Содержимое generateSPNs будет похоже на следующее:
Он просто использует параметр SetSPN для создания SPN в учетной записи службы для SQL Server.
Исправление параметра добавит SPN до тех пор, пока у вас есть право добавить SPN и показано следующее подсказка средства: Снимок экрана параметра Исправление на вкладке SPN диспетчера конфигурации 
Средство предоставляет только параметры Fix и Generate для экземпляров по умолчанию и именных экземпляров со статичными портами. Для именных экземпляров, использующих динамический порт, следует перейти от динамических к статическим портам или предоставить необходимые разрешения для учетной записи службы для регистрации и регистрации SPN при каждом запущении службы. В противном случае при каждом SQL службы необходимо вручную отрегистрируйте и перерегистрируйте соответствующие ТСД.
Вкладка Делегирования. Вкладка определяет любые проблемы с конфигурацией учетной записи службы для делегирования. Это особенно полезно при устранении неполадок связанных серверов. Например, если службы spNs проверяются нормально, но если у вас по-прежнему возникли проблемы с связанными запросами сервера, это может быть указанием на то, что учетная запись службы не настроена для делегирования учетных данных. Дополнительные сведения можно получить в разделе Книги в Интернете в разделе Настройка связанных серверов для делегирования.
После исправления СНО повторно перезапущено средство диспетчера конфигурации Kerberos и убедитесь, что вкладки SPN и Delegation больше не сообщают о сообщениях об ошибках и повторном повторе подключения из приложения.
Дополнительные сведения просмотрите следующие ссылки: