Comment empêcher l'expiration du délai d'expiration de la requête? (Erreur SQLNCLI11 '80040e31')

J'ai une connexion à un Serveur MS SQL server 2012 de la base de données classique ASP (VBScript). C'est ma chaîne de connexion:

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

Lorsque j'exécute cette commande 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;

J'obtiens l'erreur suivante:

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

La requête SQL est assez long, le champ de données est mise à jour avec 12533 caractères. La colonne ID est indexé afin de trouver le post avec l'ID 193246 devrait être rapide.

Lorsque j'exécute exactement la même expression SQL (copié-collé) sur SQL Server Management Studio, il termine avec succès en un rien de temps. Pas de problème, afin que jamais. Donc, il n'y a pas un problème avec le SQL lui-même. J'ai même essayé d'utiliser un ADODB.Objet Recordset et mise à jour par l'intermédiaire de ce (pas d'auto-écrit SQL), mais j'obtiens toujours la même erreur de dépassement de délai.

Si je vais dans Outils > Options > Exécution de la Requête dans la Gestion de Studio, je vois que le temps d'exécution est réglé à 0 (infini). Dans Outils > Options > les Concepteurs, je vois que le délai de transaction est fixée à 30 secondes, ce qui devrait être amplement suffisant car le script et la base de données est sur le même ordinateur ("localhost" est dans la chaîne de connexion).

Ce qui se passe ici? Pourquoi ne puis-je exécuter l'instruction SQL dans la Gestion de Studio, mais pas dans mon code ASP?

---

Edit: Essayé le réglage de l'30 sec délai d'attente dans l'onglet Concepteurs à 600 sec juste pour être sûr, mais j'ai toujours le même message d'erreur (qui arrive après 30 sec de chargement de la page, en passant).

Voici le code que j'utilise pour exécuter l'instruction SQL sur la page 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: à l'Aide de Conn.CommandTimeout = 0 pour donner infinie temps d'exécution de la requête ne fait rien, il fait juste de la requête à exécuter pour toujours. Attendu 25 min et c'était toujours en cours d'exécution.

J'ai ensuite essayé de séparer le code SQL dans deux instructions SQL, le long de la mise à jour des données dans l'un et l'autre des mises à jour dans l'autre. Elle n'est pas mise à jour le long du champ de données, il suffit de délai d'attente.

J'ai essayé avec deux autres chaînes de connexion:

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;

N'a pas fonctionné. J'ai même essayé de changer les données de 12533 Un est juste pour voir si les données réelles a été à l'origine du problème. Nope, même problème.

Puis j'ai découvert quelque chose d'intéressant: j'ai essayé d'exécuter le court SQL premier, avant la longue mise à jour des données de terrain. Il a ÉGALEMENT obtenu de délai d'expiration de requête d'exception...

Mais pourquoi? Il a tellement peu de choses à mettre à jour (l'ensemble de l'instruction SQL est à moins de 200 caractères). Enquêtera.

---

Edit 3: je pensais que ça aurait été quelque chose à voir avec la connexion, mais je n'ai pas trouver quelque chose qui regarde mal. J'ai même essayé de changer la chaîne de connexion à utiliser le sa-compte, mais même cela n'a pas de travail, toujours avoir de la Requête "délai d'attente expiré".

Cela me rend fou. Il n'y a pas de solution, pas de solution de contournement et le pire de tout, pas d'idées!

---

Edit 4: suis Allé dans Outils > Options > les Concepteurs dans la Gestion de Studio et coché la "Empêcher l'enregistrement des modifications qui exigent la table de re-création". Il n'a rien fait.

Essayé de changer les "données de la colonne" type de données "nvarchar(MAX)" l'inférieur "ntext" type (je suis désespéré). Il n'a pas de travail.

Essayé de l'exécution de la plus petite variation sur le post que je pouvais penser:

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

Qui permettrait de définir une colonne de bits faux. N'a pas fonctionné. J'ai essayé d'exécuter exactement la même requête dans la Gestion de Studio et cela a fonctionné parfaitement.

Me jeter quelques idées si vous en avez, car je suis à cours pour de vrai maintenant.

---

Edit 5: Ont maintenant aussi essayé la chaîne de connexion suivante:

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

N'a pas fonctionné. Seulement essayé de mettre confirmé pour de faux, mais quand même eu un temps d'arrêt.

---

Edit 6: Ont maintenant essayé de mettre à jour un autre poste dans la même table:

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

Il a également donné l'erreur de dépassement de délai. Alors maintenant, nous savons qu'il n'est pas de poste spécifique.

Je suis en mesure de mettre à jour des messages dans d'autres tables dans la même base de données via ASP. Je peux également mettre à jour des tableaux dans d'autres bases de données sur localhost.

Pourrait-il y avoir quelque chose de cassé à l' [info] le tableau? J'ai utilisé le MS Access assistant automatique de déplacer les données d'Accès à MS SQL Server 2012, il a créé des colonnes de type de données "ntext" et j'ai manuellement est allé et a changé que de "nvarchar(MAX)" depuis ntext est obsolète. Quelque chose ayant pu en panne? Elle n'a besoin de moi pour re-créer la table quand j'ai changé le type de données.

Je dois dormir un peu mais je vais vérifier demain si personne n'a répondu pour moi. S'il vous plaît ne, même si vous n'avez quelque chose d'encourageant à dire.

---

Edit 7: d'édition Rapide avant d'aller au lit. Essayé de définir le fournisseur en tant que "SQLNCLI11" dans la chaîne de connexion (en utilisant le nom de la DLL au lieu du nom du fournisseur). Il ne fait aucune différence. La connexion est créée en tant que bien, mais le délai d'attente se produit toujours.

Aussi je ne suis pas à l'aide de MS SQL Server 2012 Express (autant que je sache, "Express" n'est pas mentionné nulle part lors de l'installation). C'est la chose entière.

Si cela peut aider, voici les "Aider" > "a Propos de..." info qui est donnée par le Management Studio:

Microsoft SQL Server Management Studio: 11.0.2100.60  
Microsoft Analysis Services Client Tools: 11.0.2100.60  
Microsoft Data Access Components (MDAC): 6.3.9600.16384  
Microsoft MSXML: 3.0 5.0 6.0   
Microsoft Internet Explorer: 9.11.9600.16521  
Microsoft .NET Framework: 4.0.30319.34011  
Operating System: 6.3.9600

---

Modifier 8 (aussi connu comme le "programmeurs ne jamais dormir" edit):

Après avoir essayé quelques choses que j'ai finalement essayé de fermer la connexion de base de données et de le rouvrir à droite avant d'exécuter les instructions SQL. Il a travaillé tout d'un coup. Ce que l'...?

J'ai eu mon code à l'intérieur d'une sous-routine et il s'avère que, en dehors de ça le post que j'ai essayé de mettre à jour était déjà ouvert! Donc, la raison pour le délai d'attente est que le poste ou la totalité de la table a été verrouillé par la même connexion qui a essayé de le mettre à jour. Si la connexion (ou thread CPU) était en attente d'un verrou qui ne serait jamais déverrouiller.

Déteste quand il s'avère être si simple après avoir essayé tellement dur.

Le post avait été ouvert à l'extérieur de la sous-routine par ce simple code:

Set RecSet = Conn.Execute("SELECT etc")

Je viens d'ajouter les points suivants avant d'appeler le sous-programme.

RecSet.Close
Set RecSet = Nothing

La raison pour laquelle il n'a jamais traversé mon esprit est tout simplement parce que cela a été admis dans MS Access, mais maintenant j'ai changé pour MS SQL Server et il n'était pas si gentil (ou négligé, plutôt). La création RecSet par Conn.Execute() n'avait jamais créé un post verrouillé dans la base de données avant, mais maintenant tout d'un coup, il l'a fait. Pas trop étrange, car la chaîne de connexion et de la base de données a changé.

J'espère que ce post sauve quelqu'un d'autre, certains maux de tête si vous migrez à partir de MS Access MS SQL Server. Si je ne peux pas l'imaginer il y a que beaucoup d'utilisateurs d'Accès à gauche dans le monde d'aujourd'hui.

source d'informationauteur user3435078