Est ce necessaire de mettre cmd. ExecuteReader apres une sqlCommand??
Résolu
cs_tizguine
Messages postés
25
Date d'inscription
lundi 29 octobre 2007
Statut
Membre
Dernière intervention
16 décembre 2009
-
6 mai 2009 à 17:31
cs_tizguine Messages postés 25 Date d'inscription lundi 29 octobre 2007 Statut Membre Dernière intervention 16 décembre 2009 - 19 mai 2009 à 00:25
cs_tizguine Messages postés 25 Date d'inscription lundi 29 octobre 2007 Statut Membre Dernière intervention 16 décembre 2009 - 19 mai 2009 à 00:25
3 réponses
cs_casy
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
40
6 mai 2009 à 20:45
6 mai 2009 à 20:45
La connection à la base de données se fait par la méthode Open de ton objet connection.
Ensuite tu as le choix d'executer des requettes, des procédures stockées, ... via un objet command. Tu pourrais très bien aussi te brancher sur ta base avec un dataset via un dataadapter.
Ici en l'ocurence, ExecuteReader est à utiliser lorsque tu veux récupérer en lecture une liste d'enregistrements dans ta base, pour simplifier, récupérer par exemple le résultat d'une requette Select. Tu récupère cela dans un DataReader et tu peux ensuite utiliser ces données pour les affichées ou les traitées.
Tu as aussi la methode ExecuteScalar, qui fait exactement la même chose sauf qu'elle ne renvoie pas une liste d'enregistrement mais le 1er champ du 1er enregistrement. Utile pour une requette renvoyant qu'un seul enregistrement d'un seul champ, comme par exemple Select Count(*) ...
Ensuite tu ExecuteNonQuery. A utiliser lorsque la requette (ou procedure) ne renvoie pas de résultats, comme par exemple une requette Update. ExecuteNonQuery te renverra juste le nombre d'enregistrements qui ont été impactés par la requette.
Donc pour résumer, ce que tu vois, c'est la connection établie avec ta base. Ce qu'il faut ensuite, et ce que fait c'est diverses fonctions, c'est consommer des données.
C'est bien d'établir une connection avec une base, mais si tu n'en fait rien ensuite, ça sert pas à grand chose
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE # http://aide-office-vba.monforum.com/index.php
Ensuite tu as le choix d'executer des requettes, des procédures stockées, ... via un objet command. Tu pourrais très bien aussi te brancher sur ta base avec un dataset via un dataadapter.
Ici en l'ocurence, ExecuteReader est à utiliser lorsque tu veux récupérer en lecture une liste d'enregistrements dans ta base, pour simplifier, récupérer par exemple le résultat d'une requette Select. Tu récupère cela dans un DataReader et tu peux ensuite utiliser ces données pour les affichées ou les traitées.
Tu as aussi la methode ExecuteScalar, qui fait exactement la même chose sauf qu'elle ne renvoie pas une liste d'enregistrement mais le 1er champ du 1er enregistrement. Utile pour une requette renvoyant qu'un seul enregistrement d'un seul champ, comme par exemple Select Count(*) ...
Ensuite tu ExecuteNonQuery. A utiliser lorsque la requette (ou procedure) ne renvoie pas de résultats, comme par exemple une requette Update. ExecuteNonQuery te renverra juste le nombre d'enregistrements qui ont été impactés par la requette.
Donc pour résumer, ce que tu vois, c'est la connection établie avec ta base. Ce qu'il faut ensuite, et ce que fait c'est diverses fonctions, c'est consommer des données.
C'est bien d'établir une connection avec une base, mais si tu n'en fait rien ensuite, ça sert pas à grand chose
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE # http://aide-office-vba.monforum.com/index.php
Renfield
Messages postés
17287
Date d'inscription
mercredi 2 janvier 2002
Statut
Modérateur
Dernière intervention
27 septembre 2021
74
7 mai 2009 à 07:43
7 mai 2009 à 07:43
Pour répondre un peu plus a la question
OUI
il est nécessaire de préciser Cmd
alors oui, la connexion est ouverte et un ExecuteNonQuery n'interessera que notre connexion.
néanmoins, l'appel a ta méthode s'applique a ton obbjet représentant le lien entre ton appli et TA base.
je mets TA en avant, car tu pourrais jouer avec plusieurs connexions...
et du coup, il faudrait préciser quelle base est concernée...
"VB.Net est bête, alors, je n'ai qu'une seule connexion, y'a pas d'ambiguité..."
oui mais non ^^ un programme, ça vit. Le jour où tu ajoutes une autre connexion (base à importer, par exemple), tout ton code deviendrait ambigu, si tu n'avais pas précisé Cmd...
ExecuteNonQuery. Voilà un nom bien singulier. Mais si ta méthode s'appelait, par exemple.... ToString
Il est bien évidemment nécessaire de préciser à qui on souhaite qu'elle s'applique.
ExecuteNonQuery n'étant pas une méthode de la classe Form (là où s'execute, je pense, ton code), VB a besoin de savoir de quel objet tu parles.
Ce n'est pas de là que viennent les lenteurs que tu peux subir.
Assures toi plutot que ta requete SQL est optimisée ^^
OUI
il est nécessaire de préciser Cmd
alors oui, la connexion est ouverte et un ExecuteNonQuery n'interessera que notre connexion.
néanmoins, l'appel a ta méthode s'applique a ton obbjet représentant le lien entre ton appli et TA base.
je mets TA en avant, car tu pourrais jouer avec plusieurs connexions...
et du coup, il faudrait préciser quelle base est concernée...
"VB.Net est bête, alors, je n'ai qu'une seule connexion, y'a pas d'ambiguité..."
oui mais non ^^ un programme, ça vit. Le jour où tu ajoutes une autre connexion (base à importer, par exemple), tout ton code deviendrait ambigu, si tu n'avais pas précisé Cmd...
ExecuteNonQuery. Voilà un nom bien singulier. Mais si ta méthode s'appelait, par exemple.... ToString
Il est bien évidemment nécessaire de préciser à qui on souhaite qu'elle s'applique.
ExecuteNonQuery n'étant pas une méthode de la classe Form (là où s'execute, je pense, ton code), VB a besoin de savoir de quel objet tu parles.
Ce n'est pas de là que viennent les lenteurs que tu peux subir.
Assures toi plutot que ta requete SQL est optimisée ^^
cs_tizguine
Messages postés
25
Date d'inscription
lundi 29 octobre 2007
Statut
Membre
Dernière intervention
16 décembre 2009
19 mai 2009 à 00:25
19 mai 2009 à 00:25
tizguine
merci [auteur/CASY/333139.aspx casy] et [auteur/RENFIELD/2359.aspx Renfield], c'est tellement claire que j'ai compris pourquoi sans passer par executeReader j'ai le résultat d'une requête SELECT.
en fait j'ai definit une methode avec un DataAdapter et DataSet et donc lorsque je fais maMethode(cmd).rows(0).item(0) j'obtiens l'element à l'interssection de la premiere ligne et la premiere colonne.
merci encore une fois
merci [auteur/CASY/333139.aspx casy] et [auteur/RENFIELD/2359.aspx Renfield], c'est tellement claire que j'ai compris pourquoi sans passer par executeReader j'ai le résultat d'une requête SELECT.
en fait j'ai definit une methode avec un DataAdapter et DataSet et donc lorsque je fais maMethode(cmd).rows(0).item(0) j'obtiens l'element à l'interssection de la premiere ligne et la premiere colonne.
merci encore une fois