Как предотвратить "тайм-аут запроса истек"? (Ошибка файлом sqlncli11 'справки об 80040e31')

у меня есть подключение к базе данных MS SQL Server 2012 в классическом ASP (VBScript). Это моя строка подключения:

Provider=SQL Server Native Client 11.0;Server=localhost;
Database=databank;Uid=myuser;Pwd=mypassword;

когда я выполняю эту команду SQL:

UPDATE [info] SET [stamp]='2014-03-18 01:00:02',
[data]='12533 characters goes here',
[saved]='2014-03-18 01:00:00',
[confirmed]=0,[ip]=0,[mode]=3,[rebuild]=0,
[updated]=1,[findable]=0 
WHERE [ID]=193246;

я получаю следующую ошибку:

Microsoft SQL Server Native Client 11.0 
error '80040e31'
Query timeout expired   
/functions.asp, line 476

SQL-запрос довольно длинный, поле данных обновляется 12533 символами. Столбец ID индексируется, поэтому поиск сообщения с ID 193246 должен быть быстрым.

когда я выполняю то же самое выражение SQL (скопировано и вставлено) в SQL Server Management Studio он завершается успешно в кратчайшие сроки. Нет проблем, что так всегда. таким образом, нет проблем с самим SQL. Я даже пробовал использовать ADODB.Объект набора записей и обновление через это (без самописного SQL), но я все равно получаю ту же ошибку тайм-аута.

если я перейду в Инструменты > Параметры > выполнение запроса в среде Management Studio, я увижу, что время ожидания выполнения равно 0 (бесконечно). В разделе Инструменты > Параметры > конструкторы я вижу эту транзакцию тайм-аут установлен на 30 секунд, что должно быть достаточно, так как скрипт и база данных находятся на одном компьютере ("localhost" находится в строке подключения).

что здесь происходит? Почему я могу выполнить SQL в среде Management Studio, но не в коде ASP?


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

вот код, который я использую для выполнения SQL на странице ASP:

Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "Provider=SQL Server Native Client 11.0;
Server=localhost;Database=databank;Uid=myuser;Pwd=mypassword;"
Conn.Execute "UPDATE [info] SET [stamp]='2014-03-18 01:00:02',
[data]='12533 characters goes here',[saved]='2014-03-18 01:00:00',
[confirmed]=0,[ip]=0,[mode]=3,[rebuild]=0,[updated]=1,[findable]=0 
WHERE [ID]=193246;"

Edit 2: используя Conn.CommandTimeout = 0 чтобы дать бесконечное время выполнения запроса ничего не делает, он просто делает запрос выполнить навсегда. Ждал 25 мин,и он все еще выполнял.

затем я попытался разделить SQL на два оператора SQL, длинное обновление данных в одном и другие обновления в другом. Он по-прежнему не будет обновлять данные long поле, только что получил тайм-аут.

я попробовал это с двумя дополнительными строками подключения:

Driver={SQL Server};Server=localhost;Database=databank;Uid=myuser;Pwd=mypassword;
Driver={SQL Server Native Client 11.0};Server=localhost;Database=databank;Uid=myuser;Pwd=mypassword;

не работает. Я даже попытался изменить данные на 12533 A, чтобы увидеть, действительно ли данные вызывают проблему. Нет, та же проблема.

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

но почему? Осталось так мало вещей обновление в нем (вся инструкция SQL составляет менее 200 символов). Будем расследовать дальше.


Edit 3: я думал, что это может быть связано с логином, но я не нашел ничего, что выглядело неправильно. Я даже попытался изменить строку подключения, чтобы использовать sa-учетную запись, но даже это не сработало, все еще получая "тайм-аут запроса истек".

это сводит меня с ума. Нет решения, нет обходного пути и хуже всего нет идеи!


Edit 4: пошел в Инструменты > Параметры > конструкторы в студии управления и поставил галочку "предотвратить сохранение изменений, требующих повторного создания таблицы". Он ничего не сделал.

попытался изменить тип данных столбца " данные "с" nvarchar(MAX) "на более низкий тип" ntext " (я в отчаянии). Это не сработало.

попробовал выполнить наименьшее изменение на посту, о котором я мог думать:

UPDATE [info] SET [confirmed]=0 WHERE [ID]=193246;

это установило бы бит столбца false. Не получилось. Я попытался выполнить тот же самый запрос в студии управления, и он работал безупречно.

бросьте мне некоторые идеи, если у вас есть их, потому что я сейчас бегу по-настоящему.


Edit 5: теперь также попробовали следующую строку подключения:

Provider=SQLOLEDB.1;Password=mypassword;Persist Security Info=True;User ID=myuser;Initial Catalog=databank;Data Source=localhost

не работает. Только пытался установить подтвержденный false, но все равно получил тайм-аут.


Edit 6: теперь попытка обновить другую запись в той же таблице:

UPDATE [info] SET [confirmed]=0 WHERE [ID]=1;

он также дал ошибку по таймауту. Итак, теперь мы знаем, что это не post specific.

я могу обновлять сообщения в других таблицах в той же базе данных" databank " через ASP. Я также могу обновлять таблицы в других базах данных на localhost.

может быть что-то сломано с таблицей [info]? Я использовал мастер MS Access для автоматического перемещения данных из Access в MS SQL Server 2012, он создал столбцы данных введите "ntext", и я вручную пошел и изменил это на" nvarchar(MAX)", так как ntext устарел. Может что-то сломалось? Это потребовало от меня повторного создания таблицы при изменении типа данных.

1 ответов


оказывается, что сообщение (или, скорее, вся таблица) было заблокировано тем же самым соединением, с которым я пытался обновить сообщение.

у меня был открытый набор записей поста, который был создан:

Set RecSet = Conn.Execute()

этот тип набора записей должен быть доступен только для чтения, и когда я использовал MS Access в качестве базы данных, он ничего не блокировал. Но, по-видимому, этот тип набора записей заблокировал что-то на MS SQL Server 2012, потому что, когда я добавил Эти строки кода раньше выполнение инструкции UPDATE SQL...

RecSet.Close
Set RecSet = Nothing

...все работало просто отлично.

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