Différence entre ExecuteScalar et ExecuteNonQuery

Version imprimable

26/07/2016, 17h27
LIANAZEL

Différence entre ExecuteScalar et ExecuteNonQuery

Bonjour,

Je suis débutant en C# et j'aimerais juste connaitre la différence entre "cmd.ExecuteScalar()" et "cmd.ExecuteNonQuery().

Dans quel cas doit-on utiliser l'un par rapport à l'autre ?

Merci .

JC
26/07/2016, 17h47
DotNetMatt

Une simple recherche sur Google t'aurais fait gagner un temps precieux ;)

cmd.ExecuteScalar() retourne la premiere valeur de la premiere ligne du resultat de ta requete.
cmd.ExecuteNonQuery() retourne le nombre de lignes affectees par la commande.
cmd.ExecuteReader() retourne le resultat complet de la requete sous la forme d'un DataReader.

Bonjour DotNetMatt

Merci pour ta réponse.

Je travaille sur une requête paramétrée, et justement lorsque je fais mon " MyCommand.ExecuteNonQuery()" il ne se passe rien sur la base.

En fouillant sur le net, je suis tombé sur une discussion à propos de "ExecuteScalar()" et je me demandais si cette instruction pouvait me sortir de mon problème..

Voici mon code ( je précise que je bosse sur une base DB2/400 ) :

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
  // [ Connexion DB2/400 via la méthode "iDB2Connection" 
                    using (iDB2Connection cnx = new iDB2Connection(cnxString)) 
 
                    {
                        try
                        {
 
                            cnx.Open();
                        }
 
                        catch (Exception ex)
                        {
                            // [ Gérer traitement erreur ici ]
                            //     ( Renvoie le message d'erreur )
                            P_RESULTAT_REQUETE = ex.Message;
 
                            // [ Echec connexion... ]
                             TRT_RUN_OK = false;
 
                        }
 
 
                        iDB2Command MyCommand = cnx.CreateCommand();
 
                        string SqlCmd = "update ADMGFC_DBF.EINTRLP set  FNOMIN =  @NomMaj , FPREIN = @PrenomMaj, FFONCT = @FctnMaj ,FNMRSP = @NrspMaj , FTITRE = @TitreMaj," +
                        " FSERVA = @SrvMaj,  FUSER  = @UserMaj " +
                        " where FCHROI = @ChronoMaj";
 
                        // ( Appelle la méthode "CommandText" ) avec passage de la requête au constructeur 
                        MyCommand.CommandText = SqlCmd;
 
 
                        MyCommand.DeriveParameters();
 
                        // [ Mise en place des parameters ]
                        //  ( Nom ) 
                        MyCommand.Parameters.AddWithValue("@NomMaj", STR_INTERLO_MAJ[0].NOM_MAJ);
                        //  ( Prénom) 
                        MyCommand.Parameters.AddWithValue("@PrenomMaj", STR_INTERLO_MAJ[0].PRENOM_MAJ);
                        //  ( Fonction) 
                        MyCommand.Parameters.AddWithValue("@FctnMaj", STR_INTERLO_MAJ[0].FONCTION_MAJ);
                        //  ( Nom Responsable ) 
                        MyCommand.Parameters.AddWithValue("@NrspMaj", STR_INTERLO_MAJ[0].RESPONSABLE_MAJ);
                        //  ( Titre ) 
                        MyCommand.Parameters.AddWithValue("@TitreMaj", STR_INTERLO_MAJ[0].TITRE_MAJ);
                        //  ( Service ) 
                        MyCommand.Parameters.AddWithValue("@SrvMaj", STR_INTERLO_MAJ[0].SERVICE_MAJ);
                        //  ( User) 
                        MyCommand.Parameters.AddWithValue("@UserMaj", STR_INTERLO_MAJ[0].USER_MAJ);
                        //  ( NUM_CHRONO ) 
                        MyCommand.Parameters.AddWithValue("@ChronoMaj", STR_INTERLO_MAJ[0].NUM_CHRO_MAJ);
 
                        try
                        {
 
                            MyCommand.ExecuteNonQuery();
 
                           //  int updatedRowsCount = MyCommand.ExecuteNonQuery();
                        }
 
                        catch (Exception ex)
                        {
 
                            // [ Gérer traitement erreur ici ]
                            //     ( Renvoie le message d'erreur )
                            P_RESULTAT_REQUETE = ex.Message;
 
                            // [ Echec connexion... ]
                            TRT_RUN_OK = false;
 
                        }
 
                    }

J'ai pas de plantage, mais j'aimerais bien trouver un moyen de connaitre le résultat de mon exécution sur l'ExecuteNonQuery....:?

JC

26/07/2016, 18h07
DotNetMatt

S'il n'y a pas de plantage, c'est que la requete s'execute correctement. Est-ce que ExecuteNonQuery te retourne un nombre > 0 ?

Avant d'aller plus loin, verifie aussi que ta connection string pointe bien vers la bonne base de donnees. Ca peut paraitre bete mais on voit souvent ce genre de problem sur le forum : l'application ecrit dans une base de donnees A, et l'OP regarde dans la base de donnees B donc forcement il ne voit pas de changement...
26/07/2016, 18h51
LIANAZEL

Oui, bien sur, j'ai vérifié : je pointe bien sur la bonne adresse ip.

ExecuteNonQuery me retourne un nombre = 0.

Y doit bien avoir un moyen de savoir ce qui se passe ? :koi:

Peut -on en debuggant voir la requête telle quelle est envoyée au moteur SQL de la base ( c'est à dire sans les @...,) mais plutôt avec les vrais valeurs ?? :bug:

JC
26/07/2016, 22h19
DotNetMatt

Je ne connais pas particulierement DB2/AS400, mais sous SQL Server en utilisant le profiler on ne peut pas voir les valeurs des parametres. En gros lorsque la commande est executee, le driver envoie d'un cote la requete et de l'autre les valeurs des parametres. Ensuite SQL Server se charge du binding.

Et ce pour la simple et bonne raison que cela permet de beneficier des nombreux avantages des requetes parametrees, notamment de pouvoir mettre en cache le plan d'execution de la requete et de ne pas avoir a le recaculer a chaque fois.

Dans ton cas, tu peux tenter en supprimant les parametres, et en injectant directement les valeurs, tu verras alors si ca passe ou pas...
27/07/2016, 09h58
LIANAZEL

:salut:

Je découvre les requêtes paramétrées ( débutant C# ).

As tu deux minutes pour justement m'expliquer en gros les avantages des requêtes paramétrées ? :question:

Merci :hola: pour le temps que tu m'accordes :P

JC
27/07/2016, 10h36
François DORIN
Citation:

Envoyé par LIANAZEL

As tu deux minutes pour justement m'expliquer en gros les avantages des requêtes paramétrées ?

Il y en a au moins 3 :
- Gain en sécurité : avec une requête paramétrée, tu évites les problèmes du style injection SQL ;
- Gain en rapidité : une requête paramétrée, si elle est utilisée plusieurs fois, peut être plus rapide que l'équivalent non paramétrée. Le SGBD peut prendre un peu plus de temps pour déterminer le plan d'exécution de la requête (donc en trouver un meilleur), et il ne le fait qu'une seule fois (pas à chaque requête donc) ;
- Gain en lisibilité : Bon, la c'est subjectif, mais je trouve qu'une requête paramétrée est plus lisible (et donc maintenable) que l'équivalente non paramétrée.
27/07/2016, 10h41
LIANAZEL

Merci dorinf.

Pour ceux que cela interesse, j'ai fouillé sur le net et voici ce que j'ai trouvé :

Les avantages :

Sécurité : comme nous l'avons vu, c'est une excellente protection contre les attaques de type SQL Injection.
Rapidité : une requête paramétrée est plus rapide dans la majorité des cas qu'une requête " standard " car les données sont compilées directement avec le code au lieu d'être ajoutées dans la base de données au dernier moment juste avant l'exécution de la requête.
Lisibilité : une requête paramétrée est quand même beaucoup plus lisible qu'une requête avec des caractères de concaténation dans tous les sens, surtout quand celle-ci est complexe.

Les inconvénients :

Même si le fait d'employer des requêtes paramétrées est un atout très important au niveau de la sécurité, il ne faut pourtant pas croire que cela est suffisant. Il est indispensable de configurer correctement sa base de données, avec des comptes ayant des accès en adéquation avec leurs besoins, par exemple ne pas utiliser le compte SA pour faire un SELECT sur une table (par ailleurs, il ne faut jamais utiliser le compte SA dans une application, sauf nécessité absolue).

De plus, même si nos paramètres sont typés, cela ne signifie pas qu'il y a un contrôle du type avant l'exécution de la requête, en clair si dans un champ devant contenir un entier, un utilisateur saisit 12,43, il va alors y avoir un plantage pur et simple. Il faut donc avoir une gestion des erreurs qui soit efficace avec pourquoi pas, une vérification côté client (si le navigateur le permet) et côté serveur des données. La validation de formulaire étant très bien implémentée dans le Framework .Net, ces opérations ne sont pas difficiles à réaliser et apportent sécurité et fiabilité à votre application.

Donc, pour résumer, il n'y a pas de réel inconvénient, le seul est que l'on pourrait croire que l'emploi de requêtes paramétrées est suffisant, mais attention cela n'est pas le cas.
27/07/2016, 17h51
DotNetMatt

Merci dorinf pour le complement d'info :ccool:

Il y a un autre point a mentionner, avec une requete parametree, pas besoin de se soucier des formats (par exemple le format d'une date (yyyy-MM-dd ou dd/MM/yyyy ou ... ?) ou le format d'un decimal(1.0 ou 1,0 ou ... ?)). C'est gere automatiquement.

Et bien entendu cela ne garanti pas une securite totale en soi, mais ca reste une bonne pratique d'utiliser les requetes parametrees, quel que soit le SGBD derriere.