[C#] SqlConnection ou OleDbConnection?

Bonjour à tous!
Voilà, je dois réaliser une page aspx dans laquelle je dois afficher des informations issues d'une BDD distante. Je dois présenter ces données au sein d'un TreeView, c'est pourquoi j'aurais besoin de pouvoir récupérer les données (résultats de ma requete) une par une, et pas directement dans un dataSource (comme par exemple avec les datagrid).
Dans le code existant de l'appli que je suis en train de reprendre la plupart des pages présentent les données sous forme de DataGrid, et utilisent une OleDbConnection.
Mes questions sont donc : Comment procéder pour pouvoir récupérer les données une par une (il me semble qu'en utilisant une SqlConnection on doit pouvoir) ?
Quelle est la différence entre ces deux types de connexion?
Enfin, à quoi doit ressembler la chaine de connection pour une SqlConnection? Car j'ai repris la chaîne utilisée pour ouvrir une OleDbConnection mais elle ne semble pas fonctionner...

Merci d'avance pour vos réponses, et bonne journée à tous!

Salut,

est-ce que tu connais le type de sgbd de la base de données. Si c'est un sql server tu peux utiliser sqlconnection. Si ce n'est pas un sql server tu ne peux utiliser sqlconnection, il faut utiliser dans ce cas oledbconnection. pour trouver des informations sur les chaine de connexion va voir sur ce site

krest

Chaine de connexion :
chaine ="database=NOMBASE;server=NOMSERVER;User ID=LOGIN;pwd=PASSWORD"


SQlConnection est plus performant que OleDb pour SQL SErver car c'est un driver natif SQL Server.

Mais j'ai eu des problèmes avec SQL Connnection sur les Procédure stockées. Effectivement avec une proc stock qui a des paramètres, avec le SQL COMmand je dois nommé les paramètres de facon explicite avec les memes noms dans la requete SQL.

Alors qu'avec OleDb, il utilise pas les noms des paramètres, mais leur index (0,1,2) pour associer.

Je sais pas si j'ai été clair :)

Voila explication par l'exemple :)

Proc stock :

Code:

---

1 2 3 4 5

Creater procedure TEST @param1 as Varchar(50) AS SELECT * FROM MATABLE WHERE NOM = @param1

---

Avec un SqlCommand
il faudra faire

Code:

---

SqlCommand.paramaters.add("@param1", SqlDbType.Varchar,50)

---

alors qu'avec OleDb
on peut mettre n'importe quel nom

Code:

---

1 2	OleDbCommand.parameters.Add("totopouetpouet", OleDbType.Varchar,50)

---

Enfin perso j'ai pas trouvé comment faire avec SqlCommand pour gérer les paramètres autrement que par le nom :)

Merci à vous deux pour vos réponses express!
La BDD c'est une base Oracle, donc d'après ce que vous me dites pas possible d'utiliser SqlConnection.
Donc j'aimerai savoir comment procéder avec une connexion OleDBConnection pour récupérer les données une à une.

Par exemple avec une SqlConnection j'avais trouvé ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

// Objet connection SqlConnection myConnection = new SqlConnection(ConnectionString);   // Ouverture myConnection.Open();   // Objet Command SqlCommand command = new SqlCommand("select count(s.id_voy) tot, v.ets_ori from tfarltasi s, tfarltvoy v where s.motif_rej=6 and v.id_voy=s.id_voy group by v.ets_ori order by tot desc", myConnection);   // Objet DataReader SqlDataReader reader = command.ExecuteReader(); Object[] row = null; while (reader.Read()) { if (row == null) row = new Object[reader.FieldCount]; reader.GetValues(row); for (int i=0; i<row.GetLength(0); i++) { if (row[i] != DBNull.Value) Response.Write(row[i]); else Response.Write("NULL"); if (i < row.GetUpperBound(0)) Response.Write("|"); }   } // Fermeture reader reader.Close(); // Fermeture connexion myConnection.Close();

---

Si je me plante pas dans ce que j'ai écrit ce code récupère des données, et je récupère chaque ligne du résultat avec le SqlDataReader et je récupere chaque valeur de la ligne en faisant un "row[i]".

Donc si vous saviez comment faire mais avec une OleDbConnection ça me serait d'une grande aide!
Merci beaucoup.

Bon désolé je suis un boulet! :P
J'ai trouvé il y a les OleDbDataReader qui semble rendre les même services! :)
Je vais explorer tout ça!
Merci encore et bonne journée!

Ah tu parlais d'un mode connecté ? :p

oui OleDbDataReader :)

Citation:

---

Envoyé par SoaB

Enfin perso j'ai pas trouvé comment faire avec SqlCommand pour gérer les paramètres autrement que par le nom :)

---

Parce que tu as tellement envie que ça de rendre les appels incompréhensibles ? :)

C'est quoi le problème avec l'obligation de créer les paramètres en leur donnant les noms utilisés dans la requête, mis à part que c'est à la fois clair, lisible et logique ? :)

C'est pas générique.

Car avec OleDbconection j'ai une fonction générique qui accepte un tableau de paramètre :)

comme ca je n'ai pas 1 fonction par Proc stock :p

Donc tu préfères utiliser un provider inapproprié et réduire les performances pour ne pas avoir à faire une petite méthode toi-même tout en permettant de conserver un code plus clair ? :)

D'habitude c'est l'inverse, on sacrifie les performances pour ajouter du code afin qu'il soit plus clair. Pas pour le rendre plus obscur :)

Maniak => quand il y a 800 procédure stockées tu vas faire 800 fonctions ?

Tu vas me dire "c'est un exemple extreme jamais on rencontrera ca..."
et bah si, dernier projet sur lequel j'étais il y avait 800 proc stock peut etre plus.

POur garder un niveau générique avec SqlClient il faut aller choper en base tous les noms des paramètres de la proc stock voulue. Ca fait une double connexion. c'est en cours d'analyse.

Sinon une fonction générique peut rester très claire si elle est bien réalisée, bien commentée et si le mec qui la regarde n'est pas un débutant.

Citation:

---

Envoyé par SoaB

Maniak => quand il y a 800 procédure stockées tu vas faire 800 fonctions ?

---

Pour pouvoir contrôler le type et la validité des paramètres ? Ben oui :)

Et y a pas forcément de mapping exact entre les procédures stockées et des méthodes qui ne font rien d'autre que les appeler bêtement..

Citation:

---

Envoyé par SoaB

POur garder un niveau générique avec SqlClient il faut aller choper en base tous les noms des paramètres de la proc stock voulue. Ca fait une double connexion. c'est en cours d'analyse.

---

Ou mettre ça dans un fichier de config XML :)

Citation:

---

Envoyé par SoaB

Sinon une fonction générique peut rester très claire si elle est bien réalisée, bien commentée et si le mec qui la regarde n'est pas un débutant.

---

Vivi, le générique c'est bien. Mais c'est générique, c'est le problème :)

Avec des fonctions spécifiques, non seulement tu peux être sûr que les appels sont corrects avec des paramètres valides, tu peux effectuer discrètement tout le traitement que tu veux avant et après, s'il y a des changements dans l'interface d'une SP, tu changes 1 fonction et le compilo te sort tous les endroits où il faut reporter les modifs, ...

Ah, et ça évite de devoir se trainer le provider OleDb alors qu'on bosse sur SQLServer :)


Ça fait faire 800 méthodes, ok, mais une fois que c'est fait, c'est bien plus solide.

Tu es trop utopiste :)

Citation:

---

Envoyé par SoaB

Tu es trop utopiste :)

---

J'ai du mal à voir où est l'utopie là-dedans :)

Tout ce que je vois là, c'est le choix entre une méthode 'générique' qui sacrifie les performances et la fiabilité/résistance aux changements et une méthode qui demande de taper plus de code mais d'obtenir quelque chose de solide :)

Utiliser OleDb au lieu de Sql juste parce qu'il 'manque' une méthode permettant de passer une liste de paramètres sans indiquer les noms, c'est un peu limite comme raison :)
Au pire, tu fais un fichier de config avec nom de SP / liste de paramètres, et tu te fais 1 méthode recevant une liste d'objets et qui s'occupe du reste. C'est toujours générique (avec les dangers que ça implique), ça fait faire un poil plus de boulot une fois, mais au moins ça permet d'utiliser le bon provider. Et c'est peut-être un pas vers une meilleure isolation de la couche d'accès aux données (qui serait donc déjà de zapper cette méthode générique :)

Je ne sais pas quel age tu as et si tu tafs dans le milieu professionnel ou encore dans les études.

Mais parfois, il y a des raisons qui ne te permettent pas de croire qu'on peut toujours coder super beau super bien.

sur un projet de 1700 jours en forfait y a des choses que tu ne peux pas controler => le client :)

Par expérience, je peux te dire que, même s'ils sont parfois bizarres, les propos de Maniak sont toujours de bon conseils :wink:

Citation:

---

Envoyé par SoaB

sur un projet de 1700 jours en forfait y a des choses que tu ne peux pas controler => le client :)

---

Ouais, et le 1694 jour, 30 mn avant la présentation devant le comité de direction, un DBA facetieux décide de nettoyer une procédure et inverse l'ordre de deux paramètres...

Citation:

---

Envoyé par SoaB

Mais parfois, il y a des raisons qui ne te permettent pas de croire qu'on peut toujours coder super beau super bien.

---

T'inquiètes, je suis au courant :)

Mais il y a une différence entre ne pas pouvoir tout faire pile poil nickel chrome mais essayer, ou laisser tomber et se rabattre sur la première solution de facilité qui passe.

C'est le client qui t'impose d'utiliser OleDb au lieu de Sql pour perdre en performance tout le temps et risquer des emmerdes quand les procédures changeront 6 mois plus tard et que tu auras oublié comment marchent tes appels, mais pour gagner 30 minutes de développement une fois ? :)

Ah, et je bosse pour de vrai, avec de vrais clients qui imposent de trucs vraiment cons, donc je vois *très* bien de quoi tu parles (malheureusement :)
Dans le cas présent, c'est pas trop un facteur par contre (pas plus mal, comme ça y a pas de problème quand ils sont en grève).

Citation:

---

Envoyé par Morpheus

Par expérience, je peux te dire que, même s'ils sont parfois bizarres, les propos de Maniak sont toujours de bon conseils :wink:

---

Parfois seulement ? Zut, faut que j'y travaille :)

Citation:

---

Envoyé par Keihilin

Citation:

---

Envoyé par SoaB

sur un projet de 1700 jours en forfait y a des choses que tu ne peux pas controler => le client :)

---

Ouais, et le 1694 jour, 30 mn avant la présentation devant le comité de direction, un DBA facetieux décide de nettoyer une procédure et inverse l'ordre de deux paramètres...

---

:lol: tu es sur que tu n'étais pas avec moi sur le même projet ? :p

J'ai pas dis que c'était une super solution etc ... le constat de départ c'était juste que SlqClient ne laissait pas la possibilité d'indexer les paramètres :)

Je suis tout à fait d'accord avec vous sur le fond mais malheureusement sur ce projet à la con, il a fallu faire ainsi pour gagner énormément de temps car on était vraiment rick rack :)

Citation:

---

Envoyé par SoaB

:lol: tu es sur que tu n'étais pas avec moi sur le même projet ? :p

---

Je ne crois pas :wink: mais c'est un grand classique...

Citation:

---

Envoyé par SoaB

Je suis tout à fait d'accord avec vous sur le fond mais malheureusement sur ce projet à la con, il a fallu faire ainsi pour gagner énormément de temps car on était vraiment rick rack :)

---

Bon, je ne suis pas convaincu que le temps gagné soit si énorme...
Mais ok, imaginons que le fait de pouvoir éviter d'avoir à taper explicitement les noms des paramètres soit un gros gain; il aurait mieux vallut investir 2h pour créer un mini-tool, basé sur DeriveParameters, qui te génère les appels...

Parce que franchement, les différences de perfs entre OleDb et SqlClient ne sont pas négligeables.

C'est pour cela que nous sommes entrain de redévelopper un proxy bdd :)

Je sais bien tout ca :)

J'ai juste donner une différence entre SqlClient et OleDb :)

les paramètres ne sont pas indexés de la même facon :)