ADO.NET ou DBNetLib : pas pareil, mais pourquoi ?!!!

Le
thelastjedi
Bonjour,

Une même procédure stockée lancée depuis un appel ADO.NET (applciation
cliente en VB.NET) et depuis SQL QueryBuilder de SQLServer 2000 se comporte
différemment : via ADO.NET, ça plante en timeout à tous les coups. Via SQLQB,
lancé en ligne de commande T-SQL avec les paramètres équivalents, ça passe
sans réel problème.

Quelqu'un a-t-il une idée qui me tranquilliserait ?
Merci
--
Client : Windows XP SP2 / framework v1.0.3705.6018
Serveur : SQLServer 2005 SP2 + base en compatibilité 2000
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
TheSteph
Le #17338581
Essayez en augmentant le SqlCommand.CommandTimeout dans le programme en
VB.net. Par défaut le CommandTimeout est de 30 secondes et probablement
indéfini dans SQLQB...

Steph.

"thelastjedi" news:
Bonjour,

Une même procédure stockée lancée depuis un appel ADO.NET (applciation
cliente en VB.NET) et depuis SQL QueryBuilder de SQLServer 2000 se
comporte
différemment : via ADO.NET, ça plante en timeout à tous les coups. Via
SQLQB,
lancé en ligne de commande T-SQL avec les paramètres équivalents, ça passe
sans réel problème.

Quelqu'un a-t-il une idée qui me tranquilliserait ?
Merci
-----------------------------------------------------------------------------
Client : Windows XP SP2 / framework v1.0.3705.6018
Serveur : SQLServer 2005 SP2 + base en compatibilité 2000


Sylvain Lafontaine
Le #17339131
Question de plan d'exécution ("bad query plan" en anglais). Certains
options comme ARITHABORT ou le login (si vous ne précisez pas le schéma (par
exemple dbo.) de vos tables/SP/Views) peuvent être différentes entre les
deux systèmes ce qui peut conduire à des plans d'exécution différents. et si
un de ces plans est mauvais, vous verrez apparaître ce problème de lenteur.

La première chose à voir est d'exécuter la commande SET ARITHABORT OFF dans
le QueryBuilder avant de lancer la procédure stockée (SP) et voir si vous
aurez le même problème de vitesse. Si oui, vous pouvez regarder le plan
d'exécution et voir ce qui ne va pas avec.

La deuxième chose à faire est de voir si l'ajout de l'option WITH RECOMPILE
corrige le problème de vitesse. Si Oui, vous pouvez regarder la question du
"parameters sniffing".

Enfin, préciser le schéma de vos objets partout; clairez les caches, mettez
à jour les statistics, réindexer si nécessaire et enfin, regardez si l'ajout
de hint pour l'utilisation des indexes ne corrigera pas votre problème.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"thelastjedi" news:
Bonjour,

Une même procédure stockée lancée depuis un appel ADO.NET (applciation
cliente en VB.NET) et depuis SQL QueryBuilder de SQLServer 2000 se
comporte
différemment : via ADO.NET, ça plante en timeout à tous les coups. Via
SQLQB,
lancé en ligne de commande T-SQL avec les paramètres équivalents, ça passe
sans réel problème.

Quelqu'un a-t-il une idée qui me tranquilliserait ?
Merci
-----------------------------------------------------------------------------
Client : Windows XP SP2 / framework v1.0.3705.6018
Serveur : SQLServer 2005 SP2 + base en compatibilité 2000


thelastjedi
Le #17346731
Merci pour le tuyau.

En fait, il s'agissait d'un timeout laissé par défaut dans une SQLCommand
(c'est à dire 30s), là où le traitement en coûtait 10 de plus.

C'est corrigé. Cerise, on a même optimisé la procédure... :)

Merci encore.

"Sylvain Lafontaine" wrote:

Question de plan d'exécution ("bad query plan" en anglais). Certains
options comme ARITHABORT ou le login (si vous ne précisez pas le schéma (par
exemple dbo.) de vos tables/SP/Views) peuvent être différentes entre les
deux systèmes ce qui peut conduire à des plans d'exécution différents. et si
un de ces plans est mauvais, vous verrez apparaître ce problème de lenteur.

La première chose à voir est d'exécuter la commande SET ARITHABORT OFF dans
le QueryBuilder avant de lancer la procédure stockée (SP) et voir si vous
aurez le même problème de vitesse. Si oui, vous pouvez regarder le plan
d'exécution et voir ce qui ne va pas avec.

La deuxième chose à faire est de voir si l'ajout de l'option WITH RECOMPILE
corrige le problème de vitesse. Si Oui, vous pouvez regarder la question du
"parameters sniffing".

Enfin, préciser le schéma de vos objets partout; clairez les caches, mettez
à jour les statistics, réindexer si nécessaire et enfin, regardez si l'ajout
de hint pour l'utilisation des indexes ne corrigera pas votre problème.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"thelastjedi" news:
> Bonjour,
>
> Une même procédure stockée lancée depuis un appel ADO.NET (applciation
> cliente en VB.NET) et depuis SQL QueryBuilder de SQLServer 2000 se
> comporte
> différemment : via ADO.NET, ça plante en timeout à tous les coups. Via
> SQLQB,
> lancé en ligne de commande T-SQL avec les paramètres équivalents, ça passe
> sans réel problème.
>
> Quelqu'un a-t-il une idée qui me tranquilliserait ?
> Merci
> -----------------------------------------------------------------------------
> Client : Windows XP SP2 / framework v1.0.3705.6018
> Serveur : SQLServer 2005 SP2 + base en compatibilité 2000





Publicité
Poster une réponse
Anonyme