Приложение ADO.Net только иногда может подключиться к другому серверу в локальной сети. Кажется случайным, успешна данная попытка подключения или нет. Соединение использует строку соединения в форме:
Сервер = THESERVER \ TheInstance; База данных = TheDatabase; Идентификатор пользователя = TheUser; Пароль = Пароль;
возвращается ошибка:
Истекло время ожидания подключения. Время ожидания истекло при попытке использовать подтверждение квитирования перед входом в систему.
Это может быть связано с тем, что квитирование перед входом в систему не удалось или сервер не смог ответить вовремя.
Время, потраченное на попытки подключения к этому серверу, было - инициализация [Pre-Login] = 42030; рукопожатие = 0;
Приложение .NET - это небольшое тестовое приложение, которое выполняет следующий код:
using (SqlConnection conn = new SqlConnection(cs))
using (SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM TheTable", conn))
{
conn.Open();
int rowCount = (int)cmd.ExecuteScalar();
}
Таблица небольшая, всего 78 строк.
Однако на том же компьютере, где приложение .NET получает эту ошибку, я могу подключиться к THESERVER с помощью SSMS и идентификатора пользователя / пароля, указанного в строке подключения.
Почему может произойти сбой подключения из приложения ADO.Net, но успешный с идентичными учетными данными из SSMS?
источник
Ответы:
Оказалось, что TCP / IP был включен для IPv4-адреса, но не для IPv6-адреса из
THESERVER
.Очевидно, некоторые попытки подключения заканчивались использованием IPv4, а другие использовали IPv6.
Включение TCP / IP для обеих версий IP решило проблему.
Тот факт, что SSMS работал, оказался случайным (первые несколько попыток предположительно использовали IPv4). Некоторые последующие попытки подключиться через SSMS привели к тому же сообщению об ошибке.
Чтобы включить TCP / IP для дополнительных IP-адресов:
источник
У меня была такая же ошибка, которая подозрительно совпадала с последним раундом обновлений Microsoft (02.09.2016). Я обнаружил, что SSMS подключается без проблем, в то время как мое приложение ASP.NET возвращало «истекший период тайм-аута при попытке использовать подтверждение квитирования перед входом в систему».
Решение для меня заключалось в том, чтобы добавить тайм-аут соединения 30 секунд в строку подключения, например:
В моей ситуации единственным затронутым соединением было то, которое использовало интегрированную безопасность, и я выдавал себя за пользователя перед подключением, другие соединения с тем же сервером с использованием аутентификации SQL работали нормально!
2 тестовые системы (отдельные клиенты и серверы Sql) были затронуты одновременно, что заставило меня подозревать обновление Microsoft!
источник
Я решил проблему, как Эрик, но с некоторыми другими изменениями:
И
источник
У меня была та же проблема, когда я пытался подключиться к серверу в локальной сети (через VPN) из Visual Studio при настройке модели данных сущности.
Удалось решить только установкой
TransparentNetworkIPResolution=false
в строке подключения. В VS Add Connection Wizard вы можете найти его на вкладке Advanced.источник
У меня была такая же проблема с рукопожатием при подключении к размещенному серверу.
Я открыл центр управления сетями и общим доступом и включил IPv6 в своем беспроводном сетевом подключении.
источник
Мой исполняемый файл, созданный с использованием .NET Framework 3.5, начал сообщать об этих проблемах с подключением примерно в половине случаев после того, как недавно были установлены некоторые обновления Windows (7 августа 2017 г.).
Сбои подключения были вызваны установкой .NET Framework 4.7 на целевом компьютере (была включена автоматическая установка обновлений Windows) - https://support.microsoft.com/?kbid=3186539
Удаление .NET Framework 4.7 решило проблемы с подключением.
По-видимому, в .Net Framework 4.6.1 есть критическое изменение - TransparentNetworkIPResolution Обновление строки подключения согласно статье также решило проблему без необходимости отката версии платформы.
источник
Я исправил эту ошибку в Windows Server 2012 и SQL Server 2012, включив IPv6 и разблокировав входящий порт 1433.
источник
В нашем случае проблема возникла из-за конфигурации кластера доступности. Чтобы решить эту проблему, нам пришлось установить
MultiSubnetFailover
значение True в строке подключения.Подробнее на MSDN
источник
У меня была такая же проблема, удалось решить ее, открыв / включив порт 1433 и tcp / ip в диспетчере конфигурации SQL Server, а затем перезапустив сервер
источник
В моем случае все варианты уже были.
Решил, увеличив время ожидания подключения = 30.
источник
Прежде чем терять больше времени на решение проблемы, как я, попробуйте просто перезагрузить компьютер с Windows . Сработало для меня после применения всех других решений.
источник
У меня возникла эта проблема при миграции с SharePoint 2010 на 2013. Я подозревал, что из-за того, что сервер базы данных находится по ту сторону брандмауэра, который не маршрутизирует IP6, он пытался затем использовать IP6 и не смог подключиться к базе данных.
Думаю, проблема решена. Ошибки вроде прекратились. Я просто отключил IP6 (сняв флажок) для сетевого адаптера на серверах SharePoint.
источник
У меня была такая же проблема, но я подключался к удаленной базе данных, используя статический IP-адрес. Итак, ни одно из вышеперечисленных решений не решило мою проблему.
Мне не удалось добавить правильное сопоставление пользователей для используемого мной входа в систему безопасности, поэтому для меня решением было просто убедиться, что параметр сопоставления пользователей настроен для доступа к моей базе данных.
источник
Решена эта проблема путем блокировки / внесения в черный список IP-адресов, которые пытались взломать учетные записи пользователей. Проверьте свои журналы доступа SQL на предмет большого количества неудачных попыток входа в систему (обычно для учетной записи 'sa').
источник
На мой взгляд, брандмауэр на сервере Windows блокировал порт 1433, который является портом сервера sql по умолчанию. Так что добавление правила для входящих подключений помогло мне.
источник
В моем случае параметр
Persist Security Info=true
с пользователем и паролем в строке подключения вызывает проблему. Удаление параметра или установка дляfalse
решения проблемы.источник
Прежде чем делать что-либо радикальное, попробуйте сначала перезапустить SQL Server. Может это исправить. Это сделало для меня
источник
К сожалению, у меня была проблема с локальным SQL Server, установленным в Visual Studio, и здесь многие решения для меня не сработали. Все, что мне нужно сделать, это сбросить мою Visual Studio, перейдя по ссылке:
Панель управления> Программа и компоненты> Средство запуска установки Visual Studio
и нажмите кнопку Еще и выберите Восстановить
После этого я смог получить доступ к моему локальному серверу SQL и работать с локальными базами данных SQL.
источник
У меня была такая же проблема, которая автоматически разрешается после последнего обновления Microsoft Windows, испытывает ли кто-нибудь то же самое?
источник
У меня была точная проблема, я попробовал несколько вариантов, но не работал, наконец перезапустил систему, все работало нормально.
источник
Чтобы отследить ошибку «Истекло время ожидания соединения» , пожалуйста, убедитесь, что:
источник
Добавление здесь ответа, несмотря на ранее принятый ответ. По моему сценарию подтвердился DNS. В частности, тайм-аут DNS во время рукопожатия перед входом в систему. Изменяя DNS-имя на IP-адрес (или используя запись в файле Hosts), вы обойдете проблему. Хотя ценой потери автоматического разрешения IP.
Например, даже если для тайм-аута строки подключения установлено значение 60 на полную минуту, это все равно произойдет в течение нескольких секунд после попытки. Это наводит на вопрос, почему тайм-аут до указанного периода тайм-аута? DNS.
источник