Message : Impossible d'écrire les données sur la connexion de transport

**ac/dc** · 18/04/2013, 10h29

Bonjour,

J'ai un problème dans un programme VB .NET. Ce programme vient lire dans un FTP plusieurs fichiers XML (Restriction sur certains fichiers via leur nom). Il télécharge donc chaque fichier en local avant de les lire. Les données contenues dans chaque fichier sont ensuite insérées dans une base de données Access.

Je ne reproduis pas l'erreur, mais elle intervient chez un client.
Je ne sais donc absolument pas quelle ligne de code plante...

Ce que je peux voir dans mon fichier de log, est que la lecture dans le FTP est correcte (J'ai le nombre de fichiers dans le FTP : donc le programme accède bien au FTP), l'ouverture de la base Access à l'air de se dérouler correctement aussi.

Ensuite j'ai ce message d'erreur "Impossible d'écrire les données sur la connexion de transport.", rien de plus.

Je ne peux pas tout coller le code ici, mais déjà, savez-vous si ce type d'erreur peut intervenir sur la lecture du FTP, ou lors de l'accès à la base Access ? Toutes les pistes sont les bienvenues.

Merci.

**Bluedeep** · 18/04/2013, 11h04

Bonjour

Commencer déjà par logger les exceptions correctement, et, en livrant les fichiers pdp au client, ainsi tu aura le numéro de ligne levant l'erreur et le détail de l'exception.

**ac/dc** · 18/04/2013, 11h10

Bonjour,

Merci pour la réponse. C'est à dire que cette erreur est une erreur générique et n'est pas l'exception 1ère levée ?

Qu'est ce que sont les fichiers pdp ?

**Pol63** · 18/04/2013, 11h22

il voulait écrire pdb
ce sont des fichiers qui se trouvent à côté de l'exe après compilation et qui contiennent des infos de débuggage

par contre ce que j'ai cru voir à l'utilisation c'est que ces fichiers ne ressortent le numéro de ligne que lorsque le chemin d'origine du projet est trouvable sur la machine, auquel cas ils ne seraient pas utiles ...

par contre une bonne pratique est en effet de mettre des try catch et d'enregistrer les erreurs (ex.message, ex.Stacktrace etc...) dans des fichiers ou une base de données

**Bluedeep** · 18/04/2013, 11h25

Envoyé par ac/dc

Bonjour,

Merci pour la réponse. C'est à dire que cette erreur est une erreur générique et n'est pas l'exception 1ère levée ?

Une erreur est normalement levée sous forme d'exception. Le problème est que tu ne les log pas visiblement.

Qu'est ce que sont les fichiers pdp ?

Fichiers de symboles : en prod, ils ont un et un seul interêt, la récupération du numéro de ligne d'erreur.

**ac/dc** · 18/04/2013, 11h38

Ah oui d'accord.

ces fichiers ne ressortent le numéro de ligne que lorsque le chemin d'origine du projet est trouvable sur la machine

Je doute que le répertoire existe

Comment fait-on pour obtenir le numéro de ligne avec ces fichiers pdb ? Ca va l'écrire où ?

**Pol63** · 18/04/2013, 11h44

dans le catch, ex.Stacktrace contient la pile des appels
si les pdb sont présents et ne fonctionnent pas comme je le pense, tu auras le numéro de ligne de chaque ligne dans la pile des appels

donc si ton programme n'a pas de try catch avec log il faut commencer par le modifier et le mettre à jour chez ce client

après le numéro de ligne n'est pas toujours utile, avec ex.message souvent on peut comprendre ce qui pose problème

**Bluedeep** · 18/04/2013, 11h52

Envoyé par ac/dc

Comment fait-on pour obtenir le numéro de ligne avec ces fichiers pdb ? Ca va l'écrire où ?

Dans la stack trace de l'exception.

C'est pourquoi je t'ai suggèré :

- de logger tes exceptions complétement
- de mettre en ligne les fichier PDP sur le(s) même répertoire(s) que les exécutables associés.

**Bluedeep** · 18/04/2013, 11h52

Envoyé par Pol63

si les pdb sont présents et ne fonctionnent pas comme je le pense,

**ac/dc** · 18/04/2013, 11h53

En fait j'ai déjà un try catch, le ex.Message est justement "Impossible d'écrire les données sur la connexion de transport"...

**Bluedeep** · 18/04/2013, 12h01

Envoyé par ac/dc

En fait j'ai déjà un try catch, le ex.Message est justement "Impossible d'écrire les données sur la connexion de transport"...

Je commence vraiment à me demander si j'écrit en français ....

Logger l'exception complète pas seulement le message

**Pol63** · 18/04/2013, 12h19

Envoyé par Bluedeep

en tout cas tu n'as pas du lire mon post plus haut

j'ai déjà preté un exe à un collègue sur notre serveur, et malgré la présence de pdb, pas de ligne d'erreur dans le stacktrace (je répète au passage à ac/dc qu'il faut le stacktrace pour comprendre quelle morceau de code passe en erreur ^^)
et il n'avait les droits en lecture sur mon dossier de compilation
ca plus d'autres tests (quand on mets les pdb d'une dll dans un projet, on peut faire du pas à pas dans le code source dans le fichier .vb d'origine, et on voit bien que c'est l'emplacement du projet de la dll qui est ouvert) j'en avais déduit que les pdb sauvegardait le chemin de compilation et allait voir les fichiers sources