ADO.NET ou DBNetLib : pas pareil, mais pourquoi ?!!!
3 réponses
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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TheSteph
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" wrote in message 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
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" <thelastjedi@discussions.microsoft.com> wrote in message
news:5097EB4C-C304-4E3E-9462-E5D92E78AF70@microsoft.com...
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
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" wrote in message 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
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" wrote in message 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
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" <thelastjedi@discussions.microsoft.com> wrote in message
news:5097EB4C-C304-4E3E-9462-E5D92E78AF70@microsoft.com...
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
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" wrote in message 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
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" wrote in message 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
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" <thelastjedi@discussions.microsoft.com> wrote in message
news:5097EB4C-C304-4E3E-9462-E5D92E78AF70@microsoft.com...
> 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
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" wrote in message 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
