Err.TCP 10048 avec OleDB, Protocole TCP seul, VB6
Bonjour,
Je rencontre actuellement un souci avec une appli. se connectant sur un serveur SQL 2005 sp2 en mode TCP (RAS en mode canaux nommés).
Cette appli alimente une base sql chez des clients depuis des données fichiers et ma société ne contrôle pas forcément les protocoles acceptés par le serveur du client, d'ou : je n'ai pas le choix,je dois passer en TCP seul.
L'application ouvre deux connexions OleDB et ne les ferme qu'a la fin de tous les traitements. Tout accès à la base passant par un des deux objets connexion (le fait qu'il y en ait deux est du à l'age du code et n'en utiliser qu'un seul ne résoud pas mon problème [en plus de m'en causer d'autres, donc une chose à la fois].
Grosso modo, un traitement se décompose de la manière suivante :
[pseudocode]
[/pseudocode]
- Ouverture du/des fichier(s) en entrée
- Ouverture d'une/des tables(s) en entrée (recordset client en général)
- Ouverture d'une/des table(s) en sortie (recordsets curseur client ou serveur)
- Pour chaque enreg. lu dans un fichier
- Recherche de valeur dans x tables liés (alimentées dans des traitements précédents)
- Ecriture dans la/les table(s) en sortie
- Fermeture des tables & des fichiers
les recherches et insertions se font parfois via des commandes préparées créées au début de chaque traitement.
En mode TCP, une erreur 10048 du provider TCP (TCP Provider: Une seule utilisation de chaque adresse de socket (protocole/adresse réseau/port) est habituellement autorisée.) se produit rapidement.
Des connections TCP sont ouvertes & fermées sans arrêt durant le traitement (jamais plus de 4/5 et en plus des deux qui sont clairement liées aux connexions Ole ouvertes au début et qui ne disparaissent qu'a la fermeture des connexions Ole) mais Windows conservant par défaut une connection TCP pendant 2mn, la limite (par défaut aussi) des 5000 connections temporaires est atteinte et là, c'est le drame.
Pour l'instant, j'arrive à passer en modifiant la base de registre du poste client pour passer le nombre de connexions TCP temporaires au max. (le volume de données à transférer pouvant varier de quelques Mo à quelques centaines, impossible de prévoir au plus juste) et en faisant descendre le délai de rétention de ces connexions TCP temporaires à 30s.
Mais ça ne convient pas vraiment.
Je soupconne (et je suis en train de chercher/vérifier) l'utilisation des commandes préparées d'être à l'origine de ces connexions courtes mais pourquoi car les c'est toujours les mêmes 2 connexion Ole qui sont utilisées ?
Donc, pour finir, mes questions sont :
Pourquoi toutes ces connexions TCP alors que j'utilise toujours le même objet connexion OleDB quelque soit l'ordre SQL et qu'il y a des traitements durant lesquels AUCUNE connexion TCP supplémentaire (en plus des 2 "normales") n'est créée (je vais vérifier qu'il n'y a pas de commandes préparées dans ces traitements) ?
Et si c'est un fonctionnement normal du provider ADO, Y a-t-il moyen de le forcer (via une propriété sur la connexion ou autre) à limiter le nombre de connexions TCP ou à détruire ces connexions ou du moins dire à l'OS de le faire plus rapidement sans modifier la base de registre ?
Merci d'avance,
Infos :
OS Serveur : 2000, 2003 (pas testé avec XP)
OS Client : XP (pas testé avec d'autres OS)
SGBD : SQL Serveur 2005 SP2
Langage : VB6 sp6
Client BD : ADO 2.8
& Client Natif SQL Server (SQLNCLI)
Répondre avec citation
Partager