Adresse de Fichiers string et c#

Bonjour à tous et à toutes,
Je migre progressivement de vb vers c#.
J'avoues que j'aime bien le langage c#.
J'ai un petit soucis avec l'enregistrement d'une adresse de fichier Local en particulier \ qui doit être reservé dans le langage comme il y en a en VB.
En Vb pour ignorer dans un string les caractères spéciaux réservés il fallait les doubler.
ET la on met le symbole @ devant le string pour lui spécifier certainement que c'est une adresse locale afin d'ignorer les caractères speciaux.
J'essaie de stocker une adresse dans une BDD mais il ne m'intègre pas les caractères spéciaux ? et bien sur il ne me relie pas l'adresse correctement non plus.
Faut il comme en VB doubler ces caractères ou une autre astuce ?

Code:

---

1 2 3 4 5

string adresse = @"" + (string)dr.Cells[2].Value + ""; Requete2="Insert into param SET IdReference='" + (string)dr.Cells[0].Value +"' , Client='"+ (string)dr.Cells[1].Value+"' , FichierSource='"+adresse+"';"; OdbcCommand cmd = new OdbcCommand(Requete2,cn5); cmd.ExecuteNonQuery();

---

Merci

Le @ n'est pas fait pour ignorer les caractères spéciaux.
Il est fait pour annuler l'interprétation de l'antislash (\).
Ceci a également pour effet que pour échapper un guillemet double, il faut en mettre deux.

Imaginons que ta cellules contienne la chaine suivante : C:\Users\popo\AppData\Local\MyApplication.
alors (string)dr.Cells[2].Value va contenir ceci : C:\\Users\\popo\\AppData\\Local\\MyApplication

De ce fait puisque, tu mets à un @, tu dis que le l'antislash n'est considéré comme un caractère d'échappement.
En plus, tu double le guillemet.
Tu va donc te retrouver avec "C:\\Users\\popo\\AppData\\Local\\MyApplication" dans ta base de données.

La bonne solution est de passer par les requêtes paramétrées (à adapter à ta structure)

Code:

---

1 2 3 4 5 6

Requete2="Insert into param SET IdReference=@IdReference , Client=@Client , FichierSource=@Adresse"; OdbcCommand cmd = new OdbcCommand(Requete2,cn5); cmd.Parameters.Add("@IdReference", OdbcType.NVarChar, 10).Value = (string)dr.Cells[0].Value; cmd.Parameters.Add("@Client ", OdbcType.NVarChar, 10).Value = (string)dr.Cells[1].Value; cmd.Parameters.Add("@Adresse", OdbcType.NVarChar, 10).Value = (string)dr.Cells[2].Value; cmd.ExecuteNonQuery();

---

Merci popo maiis... Helas non cela ne fonctionne pas.
Je stock dans Mysql pour info.
pour info ce sont des VARCHAR(45) les champs de la table de réception.

Avec ma méthode je me retrouvais avec un chemin d'accès sans les \ stocké dans la table en Gros Z:REP1REP2FICHIER.EXT
A PRESENT j'ai juste NULL et ce dans tous les champs de la table que j'ajoute


Que vaut 10 dans tes paramètres ? la longueur de la chaine envoyée ?

Merci de te pencher sur mon soucis c'est sympa.

Je n'ai évidemment pas corrigé ta requête car je pensais que tu verrais ton erreur tout seul.

La syntaxe d'une requête d'insertion est la suivante : INSERT INTO Table (Champ1, Champ2) VALUES ('Valeur1', 'Valeur2')

Donc ta requête devrait être :

Code:

---

INSERT INTO param (IdReference, Client, FichierSource) VALUES(@IdReference, @Client, @Adresse)

---

Edit :
Mais comme tu utilises le couple ODBC + MySQL, essaie avec la syntaxe suivante si la première ne fonctionne pas :

Code:

---

INSERT INTO param (IdReference, Client, FichierSource) VALUES(?, ?, ?)

---

Et oui, 10 est la longueur.
Sinon tu peux utiliser cmd.Parameters.AddWithValue

Je ne pense pas que ce soit le format de ma requete

Mon Format

Code:

---

1 2 3

INSERT INTO TABLE SET Idreference='A05455' , Client='TOTO' , FichierSource='C:\Test\Fichier.txt';

---

car ce format a toujours fonctionné et fonctionne pour d'autre requête ne comportant \ dans les chaines envoyés.

Je viens d'essayer ton format de Requête ( que je connais tu peux même faire avec seulement les valeurs sans les noms des champs si tu respecte l'ordre de la base) mais qui ne change strictement rien je ne reçois que des champs Null;
J'ai mis un point d'arrêt et regardé les paramètres les valeurs sont bien chargé dans les paramètres.

J'ai tenté de modifier la chaine de caractère \ par des \\ ce que je faisait en vb.net ( et ca fonctionne en VB) mais la non ou il y a un paramètre dans la base de donnée a conf quelquepart.

Ca fonctionne avec la syntaxe des points d'interrogations

Merci bien

Juste une autre question quand je récupère par contre mon fichier il est de la forme suivante :
C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext

une idée pourquoi il me double les antislash si je transfert la variable de retour dans un label je ne vois C:\REPERTOIRE1\REPERTOIRE2\FICHIER.ext MAis si je récupère label9.text j'ai a nouveau les antiSlash doublés?
il y a une différence entre affichage et variable

ca va me rendre dingue je trouve pas de Logique

Code:

---

1 2	string Adresse =Convert.ToString( cmd.ExecuteScalar());

---

Adresse se retrouve sous cette forme C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext alors que dans la base elle est sous celle ci C:\REPERTOIRE1\REPERTOIRE2\FICHIER.ext

SQL qui merdouille ou C#
Cdt

L'antislash dans le code C# est un caractère d'échappement qui doit être suivi par une constante "d'échappement"
Ainsi :
"\t" est une tabulation
"\r" est un retour chariot
"\n" est un caractère de "nouvelle ligne".

Cela implique que si on veut écrire un antislash, on doit le doubler.
"\\" est un antislash unique.

On l'utilise également pour mettre un guillemet double dans une sinon
"\"" représente le caractère " (guillemet double).
Sans l'antislash C# l'interpréterai comme la fin de la chaine.

Lorsque tu places un @ devant le début de la chaine, cela annule l'interprétation de l'antislash (\).
Puisqu'il n'est plus interprété, il est considéré comme un caractère basic.

@"\t" représente un antislash suivi d'un t
@"\r" représente un antislash suivi d'un r
@"\n" représente un antislash suivi d'un n
@"\\" représente deux antislashs
@"\"" ne compile pas car représente un antislash suivi d'un unique guillemet double, et du coup la chaine n'est pas terminée.
@"\""" représente un antislash suivi d'un unique guillemet double

Code:

---

1 2 3 4

// Ces deux chemins sont les mêmes String path1 = "C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext"; String path2 = @"C:\REPERTOIRE1\REPERTOIRE2\FICHIER.ext";

---

L'Interface de débogage de l'IDE présente la chaine telle qu'elle est vue par C# (avec les caractères d'échappement).
Ceci est normal.

Si tu écrits ceci :

Code:

---

1 2 3

String path = @"C:\REPERTOIRE1\REPERTOIRE2\FICHIER.ext"; MonLabel.Text = path;

---

La variable path sera affichée "C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext" dans l'IDE.
MonLabel.Text sera affichée "C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext" dans l'IDE.
Le label dans l'écran affichera C:\REPERTOIRE1\REPERTOIRE2\FICHIER.ext

Si tu écrits ceci :

Code:

---

1 2 3

String path = @"C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext"; MonLabel.Text = path;

---

La variable path sera affichée "C:\\\\REPERTOIRE1\\\\REPERTOIRE2\\\\FICHIER.ext" dans l'IDE.
MonLabel.Text sera affichée "C:\\\\REPERTOIRE1\\\\REPERTOIRE2\\\\FICHIER.ext" dans l'IDE.
Le label dans l'écran affichera C:\\REPERTOIRE1\\REPERTOIRE2\\FICHIER.ext

Donc, puisque ton chemin n'est pas en dur dans le code mais provient d'un autre source, enlève l'arobase.

Merci popo,
En fait le problème vient du fait que j'utilise l'adresse du fichier via le lecteur logique attribuer et pas l'adresse UNC du Fichier avec cette dernière elle s'ouvre correctement et avec tous les \ dans le string.

Adresse
Z:\\Rep1\\rep2\\Fichier.ext --> Marche pas
\\\\SRV-ad\\RepX\\Rep1\\Rep2\\Fichier.ext --> ca marche

Ce sont des particularités du Langage qu'il faut que j'apprenne ca VB fonctionnait bien avec les lecteurs Logiques.

Faut que je vois comment je chope l'adresse UNC d'un fichier en donnant une adresse Logique par copier coller. (autre Topic si je trouve pas)

:-)

Merci tes explications sont assez claires au niveau de \

Pour ta base de données, il n'y a aucune différence.
Ce sont simplement des chaînes de caractères.

Il n'y a donc aucune raison pour que les deux chemins soient enregistrés de manières différentes dans la base de données.

J'arrive a ouvrir une adresse UNC mais pas celle avec le réseau ( faut que je fasse un test en local).
Dans Explorateur windows si je copie l'adresse de la SGBD avec le lecteur logique l'explorateur ne trouve pas la cible
Mais si je mets l'adresse UNC ca marche il doit y avoir un truc Mais ce n'est pas lié a mon programme mais certainement a l'infrastructure réseau.
doit avoir un problème avec l'alias du lecteur Logique.