IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Forms Discussion :

Utilisation de parametres pour les requêtes SQL


Sujet :

Windows Forms

  1. #1
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut Utilisation de parametres pour les requêtes SQL
    Bonjour, j'aurai voulu avoir quelques renseignements sur l'utilisation de paramètres lors de l'exécution d'une requête sql INSERT INTO
    Voila mon problème
    Je veux enregistrer une personne dans ma table et récupérer l'ID générer automatiquement. J'utilise des paramètres (j'ai lu que c'était plus sécurisé) mais ma requête ne passe pas
    Voici le code associé
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    
    //Declaration globale
            private const string PARM_Nom = "@Nom";
            private const string PARM_Prenom = "@Prenom";
            ...
    object[] ICandidat.AddCandidat(CandidatInfo Candidat)
    {
            //Corps de la methode
             string SqlAdd = "INSERT INTO Personne (Nom, Prenom, ... ";
             SqlAdd = SqlAdd + VALUES(@Nom, @Prenom,...";
             SqlAdd = SqlAdd + "); SELECT @@IDENTITY;";
    
    SqlParameter[] parms {	   
            new SqlParameter(PARM_Nom, SqlDbType.VarChar),
            new SqlParameter(PARM_Prenom, SqlDbType.VarChar),
            ...
    };
            parms[0].Value = Candidat.NomFr;
            parms[1].Value = Candidat.PrenomFr;
            ...
            SqlConnection conn = new SqlConnection(SqlHelper.ConnectionString);
            conn.Open();
            SqlTransaction trans = conn.BeginTransaction(IsolationLevel.ReadCommitted);
            object ID;
            object[] Resultat = new object[2];
    
            try
            {
                 ID = SqlHelper.ExecuteScalar(trans, CommandType.Text, SqlAdd,parms);
                 trans.Commit();
                 Resultat[0] = bool.Parse("true");
                 Resultat[1] = int.Parse(ID.ToString());
                 return Resultat;
            }
            catch
            {
                 trans.Rollback();
                 Resultat[0] = bool.Parse("false");
                 Resultat[1] = int.Parse("0");
                 return Resultat;
            }
            finally
            {
                 conn.Close();
            }
    }
    
    public static object ExecuteScalar(SqlTransaction transaction, CommandType commandType, string commandText, params SqlParameter[] commandParameters)
    {
            if (transaction == null) throw new ArgumentNullException("transaction");
                if (transaction != null && transaction.Connection == null) throw new ArgumentException("The transaction was rollbacked or commited, please provide an open transaction.", "transaction");
    
            // Create a command and prepare it for execution
            SqlCommand cmd = new SqlCommand();
            bool mustCloseConnection = false;
            PrepareCommand(cmd, transaction.Connection, transaction, commandType, commandText, commandParameters, out mustCloseConnection);
    
            // Execute the command & return the results
            object retval = cmd.ExecuteScalar();
    
            // Detach the SqlParameters from the command object, so they can be used again
            cmd.Parameters.Clear();
            return retval;
    }
    
    private static void PrepareCommand(SqlCommand command, SqlConnection connection, SqlTransaction transaction, CommandType commandType, string commandText, SqlParameter[] commandParameters, out bool mustCloseConnection)
    {
            if (command == null) throw new ArgumentNullException("command");
            if (commandText == null || commandText.Length == 0) throw new ArgumentNullException("commandText");
    
            // If the provided connection is not open, we will open it
            if (connection.State != ConnectionState.Open)
            {
                 mustCloseConnection = true;
                 connection.Open();
            }
            else
            {
                 mustCloseConnection = false;
            }
    
            // Associate the connection with the command
            command.Connection = connection;
    
            // Set the command text (stored procedure name or SQL statement)
            command.CommandText = commandText;
    
            // If we were provided a transaction, assign it
            if (transaction != null)
            {
                 if (transaction.Connection == null) throw new ArgumentException("The transaction was rollbacked or commited, please provide an open transaction.", "transaction");
                    command.Transaction = transaction;
            }
    
            // Set the command type
            command.CommandType = commandType;
    
            // Attach the command parameters if they are provided
            if (commandParameters != null)
            {
                 AttachParameters(command, commandParameters);
            }
            return;
    }
    La ligne en gras est apparemment celle qui plante
    Donc voici les questions
    - Quand est ce que les paramètre sont insérer dans la requête? Est ce justement au sein de la méthode ExecuteScalar()?
    Car lors du debuggage, si je regarde les propriétés de l'objet cmd, les paramètres sont encore dans la requête et non les valeurs.
    - Est vraiment plus sécurisé d'utiliser des paramètres plutôt que de passer les valeurs directement dans la requête?
    - Lors de la déclaration des constantes, le type doit il obligatoirement être un string même si l'enregistrement en base de donnée est un int ou une date?

    J'avoue être un peu perdu avec l'utilisation des paramètres
    Je précise que je reprend le code d'une personne avant moi que je ne peut contacter

    SI une âme charitable veux bien m'aider, merci d'avance

  2. #2
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    Oui utiliser les requêtes paramétrées est plus sécurisé, mais attention c'est pas "j'utilise les paramètres, donc mon appli est invulnérable.".

    Pour utiliser les requetes SQL paramétrées voilà un exemple simple:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
                //Paramètres de connexion
                Connect();
    
                //Définition des SQLParameters
                MySqlParameter param_nom = new MySqlParameter("@nom", MySqlDbType.String, 50);
                //On associe à la variable récupérée précédemment
                param_nom.Value = [une_valeur];
    
                //On recommence pour autant de paramètres qu'on veut
    
                //On définit la requête SQL
                String sql = string.Format("INSERT INTO ***(NOM, ***) VALUES({0},***)", param_nom.ParameterName);
                MySqlCommand cmd = new MySqlCommand(sql.ToString(), Connection);
                //On ajoute les paramètres définis à la commande SQL
                cmd.Parameters.Add(param_nom);
    
                 try
                {
                    Connection.Open();
                    //Exécution requête
                    cmd.ExecuteNonQuery();
                   Connection.Close();
                }
    
                catch
                {
                    // Si la connexion a échoué, message d'erreur                
                    Connection.Close();
                }
    EDIT : c'est pas la méthode avec executeScalar, mais NonQuery, mais bon, le principe y est .

  3. #3
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    En fait j'utilise ExecuteScalar car je veux recupérer l'ID créer car j'en ai besoin pour la suite et que c'est un peu plus propre que de refaire une requête

    Et quand je fais ça ça revient au même que ta chaine d'insertion?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
             string SqlAdd = "INSERT INTO Personne (Nom, Prenom, ... ";
             SqlAdd = SqlAdd + VALUES(@Nom, @Prenom,...";
    PS : Bon je viens de m'apercevoir que j'ai oublié la méthode qui construit la commande sql, j'edit mon premier message

  4. #4
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    C'est pas ça, regarde ici les différences entre les types d'éxécution de requêtes : (c'est en anglais sorry)

    Ce que tu veux faire est mieux avec execute non query...pas besoin de executescalar là...

  5. #5
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Ok donc je vais tester avec ExecuteNonQuery
    Et pour les autres questions?


    Apres test le NonQuery ne fonctionne pas non plus
    Voici le code
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
            public static int ExecuteNonQuery(SqlTransaction trans, CommandType cmdType, string cmdText, params SqlParameter[] commandParameters) {
                SqlCommand cmd = new SqlCommand();
                PrepareCommand(cmd, trans.Connection, trans, cmdType, cmdText, commandParameters);
                int val = cmd.ExecuteNonQuery();
                cmd.Parameters.Clear();
                return val;
            }
    Toujours une erreur lors de l'exécution de la requête
    Il doit y avoir une erreur ailleurs mais j'arrive pas a identifier ou

  6. #6
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    Alors dans l'ordre :

    • - Quand est ce que les paramètre sont insérer dans la requête? Est ce justement au sein de la méthode ExecuteScalar()?
      Car lors du debuggage, si je regarde les propriétés de l'objet cmd, les paramètres sont encore dans la requête et non les valeurs.
      Réponse dans mon code; D'abord tu crée ton paramètre, tu lui assigne une valeur, tu insère dans ta string de requete au lieu des valeurs des {0}, {1}, etc. à la fin de ta requête tu met une virgule, puis dans l'ordre tu associe les paramètre (le premier sera associé à {0}, etc.). Enfin apres ta commande de requete tu ajoute tes paramètres. finalement tu exécute! (tout est dans le code que je t'ai donné)
    • - Est vraiment plus sécurisé d'utiliser des paramètres plutôt que de passer les valeurs directement dans la requête?
      OUI! Il existe des attaques dites "d'injection SQL" où les champs (textboxs, etc.) sont utilisées pour injecter des requetes pirates qui affecteraient ta base, là pas de rique là dessus. Après c'est plus rapide car compiler avec le code. Pour de plus ample infos, voilà un super lien :
    • - Lors de la déclaration des constantes, le type doit il obligatoirement être un string même si l'enregistrement en base de donnée est un int ou une date?
      Généralement oui, du moment que tu as une seule string, et puis ça mange pas de pain!
      Après tu doit paramétrer tes paramètres (elle est belle celle-là ), et définir le type de données de ton paramètre:

      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
       
      MySqlParameter param_prix = new MySqlParameter("@prix", MySqlDbType.Double);
                  paramprix.Value = variable_du_prix;


    Voilà, j'ai répondu à tout?

  7. #7
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Oui a peut près a par pour la première question
    J'ai bien compris qu'il faut construire la string avec les paramètres, d'ailleurs c'est comme ça que je l'ai fait
    Mais je voulais savoir a quel moment les paramètres sont remplacés par leurs valeurs dans la chaine?
    Car quand je repasse en mode debuggage, la propriété CommandText de l'objet SqlCommand contient encore la chaine avec le nom des paramètres et pas leur valeur.

    Je sais je suis chiant mais j'aimerais bien comprendre le fonctionnement et surtout pouvoir comprendre d'où viens le problème dans mon code

  8. #8
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    Citation Envoyé par Saten Voir le message
    Pour de plus ample infos, voilà un super lien :
    (Première fois que je me cite )
    Dixit le lien:
    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.
    Regardons le code en semble:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    MySqlParameter param_nom = new MySqlParameter("@nom", MySqlDbType.String, 50);
                param_nom.Value = String_Nom;
    >>La ton paramètre prend en paramètre "@nom", et en valeur "String_Nom". Après cette ligne en Debug, tu verra que param_nom aura comme base "@nom" et en Value = String_Nom

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    String sql = string.Format("INSERT INTO ***(NOM, ***)  VALUES({0},***)", param_nom.ParameterName);
    >> La tu as une string (ta requete) qui contient un/des paramètres. Ces paramètres désignés, mais pas ajoutés.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    MySqlCommand cmd = new MySqlCommand(sql.ToString(), Connection);
    >>Tu crée une commande qui éxécutera ta chaine (requête). Donc tu l'associe à la string "sql".

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    cmd.Parameters.Add(param_nom);
    >>La tu ajoute à ta commande le paramètre ou les paramètres.

    T'ais-je éclairé un peu?

    EDIT:
    la propriété CommandText de l'objet SqlCommand contient encore la chaine avec le nom des paramètres et pas leur valeur.
    En debug, place le curseur sur ton paramètre, tu verra à droite sa base: "@nom", clic sur le petit "+" pour agrandir la fenetre, et en bas, tu aura VALUE = "String_Nom" .

  9. #9
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Ok je dois pas bien m'exprimer semble t il

    Je sais déjà tout ça (enfin tout du moins j'ai compris le fonctionnement)
    Et le fonctionnement de VS je le connais
    Moi ce que je voudrais savoir c'est si on peut voir clairement à un moment ou a un autre dans les propriétés de l'objet la chaine avec les valeurs ex : "INSERT INTO PERSONNE (Nom,Prenom,....) VALUES ('Durant','Toto',.....)"
    et non pas la chaine "INSERT INTO PERSONNE (Nom,Prenom,....) VALUES(@Nom,@Prenom,...)

    Tu me comprend mieux?
    D'où ma question, dans à quel moment la chaine est elle construite?
    Si je demande ça c'est non seulement pour me coucher moins bête ce soir mais également pour pouvoir copier la chaine afin de tester directement une requête SQL pour voir si mon erreur ne vient pas de la requête elle même

  10. #10
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    Moi ce que je voudrais savoir c'est si on peut voir clairement à un moment ou a un autre dans les propriétés de l'objet la chaine avec les valeurs ex : "INSERT INTO PERSONNE (Nom,Prenom,....) VALUES ('Durant','Toto',.....)"
    et non pas la chaine "INSERT INTO PERSONNE (Nom,Prenom,....) VALUES(@Nom,@Prenom,...)
    Et bien non... c'est le principe de la requête paramétrée, les paramètres sont compilés, et je re-dixit mon lien: "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".
    Tu auras toujours ta requêtes : "INSERT INTO PERSONNE (Nom,Prenom,....) VALUES({0},{1},...), param_nom.ParameterName, param_prenom.ParameterName,...".
    Mais en debug tu verra que param_nom.Value = "Durant", et que donc {0} = "Durant", donc c'est que c'est good .

  11. #11
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Oui donc je ne peux pas directement tester ma requête alors
    Encore une petite question du coup :p
    Est ce que les valeurs qu'on voit dans le champs valeur sont exactement égales à ce qui est insérer dans la requete final?
    Je m'explique sur cette question
    Je viens de m'apercevoir que la valeur de la date de naissance était celle ci {25/11/2008 00:00:00} . Le problème d'enregistrement viendrait donc de cette date? Ce que je comprend pas c'est que cette date en question est issu d'un DateTimePicker qui en théorie renvoi un datetime
    Pourquoi ces accolades?
    Desolé je m'écarte un peu du sujet de base mais maintenant ça serais bien que ça fonctionne

    Je continue de tester et j'edit au besoin

    Merci de tes réponses
    Plus qu'a finir de debugguer :/

  12. #12
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    C'est normal oui! Toutes les dates seront affichées de la sorte! Les accolades, ça c'est le débogueur de VS qui affiche les dates comme ça. Mais rassures-toi, il la change quand même!
    Selon le type de date dans ta base (et ta base de donnée aussi ), il faudra peut-être parfois la convertir.

    voilà un exemple pour les paramètres :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    DateTime madate = DateTime.ParseExact(string_comprenant_la_date, "ddMMyy", null);
                MySqlParameter paramdate = new MySqlParameter("@date", MySqlDbType.Date);
                paramdate.Value = madate;
    Edit: ça c'est pour convertir une string en date, jsuis à côté d'la plaque ^^

    Tu verra toujours tes dates dans ce format, même avec l'heure, mais t'inquiète si tu demande la date, il mettra que la date.

    re-edit:
    Ce que je comprend pas c'est que cette date en question est issu d'un DateTimePicker qui en théorie renvoi un datetime
    Bah oui, tu as une date et une heure... Donc tu insèreras dans ta base une date et une heure, donc ta base de données doit être configurée pour recevoir ça. Si tu n'a mis que Date dans ta table, alors ça marchera pas, il faudra DATETIME.

    tripl-edit :
    Je viens de m'apercevoir que la valeur de la date de naissance était celle ci {25/11/2008 00:00:00}
    Heu.. C'est quoi le problème, c'est un test cette date, ou ton datetimepicker marche pas?

  13. #13
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    En faite c'était pour le format avec les accolades
    Mais tu y as déjà répondu en disant que c'était normal

    Bon du cou je sais vraiment pas pourquoi la requête ne fonctionne pas étant donné que j'ai copier la chaine créer et remplacé par les valeurs des paramètres et que l'enregistrement ses très bien effectuer avec Entreprise manager (j'utilise SQL Serveur )

    Et pour répondre a la question oui mon type est bien un datetime dans ma base de données, tout comme le type du paramètre

    Et je sais que le problème ne viens pas non plus de la connexion a la bdd car le formulaire arrive très bien a récupérer les données dans la base

  14. #14
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    Quand tu envoies une requête à ton SQL Server, quand tu remplace les paramètres par des noms bidons, ça marche ou pas?

    (j'imagine que tu as déjà essayé non?)

  15. #15
    Membre émérite
    Inscrit en
    Octobre 2006
    Messages
    587
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Octobre 2006
    Messages : 587
    Par défaut
    Les noms ne sont pas pris en compte par SQL Server par contre ce n'est pas le cas des autres SGBDR.

    Par contre méfie toi de la méthode Parse des types valeurs, elle déclenche une exception de type FormatException lorsque la conversion est impossible.

    Pourquoi ne pas mettre le littéral true directement ?

    Evite aussi d'utiliser des tableaux de type object car ils seront très faiblement typés vu que l'on peux stocker n'importe quoi dedans. De plus, le programme peut demander des opérations boxing dans le cas de types valeurs.

    Dernière chose: Dans ton finally, je pense que tu as oublié de libérer l'objet trans de type SqlTransaction.

  16. #16
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Citation Envoyé par Saten Voir le message
    Quand tu envoies une requête à ton SQL Server, quand tu remplace les paramètres par des noms bidons, ça marche ou pas?

    (j'imagine que tu as déjà essayé non?)
    Honte a moi j'étais tellement a fond dans les paramètres hier que je n'y avais pas penser, ce n'est que ce matin sur le chemin du boulot que j'ai tilté :/ (comme quoi travailler 9h par jour c'est pas vraiment rentable :/)
    Donc résultat je sais d'où vient l'erreur, tout simplement d'un champs photo qui est un tableau de byte mais qui en l'occurrence est nulle. Or quand la requête est exécuté, le null se transforme en "" et du cou ça plante car on se retrouve avec "... , , ..." :/

    Une idée pour que dans ma requête finale null soit apparent? je parle de la requête avec les paramètres bien sur
    Après quelques minutes je suis en train de me demander si c'est vraiment possible étant données qu'on a pas accès à la requête final avec les paramètres
    Ça me semble quand même étrange cette histoire.

    PS : Dans ma base de données ce champs autorise les valeur null



    Les noms ne sont pas pris en compte par SQL Server par contre ce n'est pas le cas des autres SGBDR.
    Que veux tu dire par la?


    Pourquoi ne pas mettre le littéral true directement ?
    Tout simplement parce que je suis fatigué et que j'aime me compliquer

  17. #17
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Up
    Les informations de ma requêtes sont bonnes car je l'ai testé en insérant directement les valeurs sans passer pas les paramètres. Mais si j'utilise les paramètres je me retrouve avec une erreur

    Les noms ne sont pas pris en compte par SQL Server par contre ce n'est pas le cas des autres SGBDR.
    Peut tu préciser l'information s'il te plait?
    Ça veux dire que je peut pas utiliser "@Nom" dans la requête?

    Je sent qu'il ne manque pas grand chose pour que ça fonctionne mais quoi? La est toute la question

  18. #18
    Membre confirmé Avatar de Saten
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 203
    Par défaut
    Pour @Nom, c'est pas le problème, tu pourrais mettre @toto ce serait pareil.
    Je pense que ça vient du fait de SQL Server, car moi avec MySql, je t'ai tout donné, et tout a roulé comme sur des roulettes, sans soucis... Mais je n'ai jamais utilisé SQL Server...

  19. #19
    Membre averti
    Inscrit en
    Novembre 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Novembre 2008
    Messages : 22
    Par défaut
    Pour @Nom, c'est pas le problème, tu pourrais mettre @toto ce serait pareil.
    Oui je m'en doute bien
    Ce que je voulais dire par la c'est qu'avec la remarque précédente et en regardant le code que tu avais posté, je me suis demandé si j'avais le droit d'utiliser des noms avec SQLServer (@...)
    Car toi tu as fais ainsi
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    String sql = string.Format("INSERT INTO ***(NOM, ***)  VALUES({0},***)", param_nom.ParameterName);
    Tu n'as pas utiliser @Nom mais remplacer par "{0}" et rajouté a la fin "param_nom.ParameterName"

    Je vois pas d'où viendrais le problème mais c'est la remarque qui me fais douter
    A moins que j'ai rien compris de ce qu'il voulais dire

    EDIT : En relisant mes posts je mapercoit que j'ai oublié de préciser que le champs photo ne doit plus être un problème étant données que j'ai modifier le type pour finalement recevoir le chemin de l'image et non l'image elle même

  20. #20
    Membre émérite
    Inscrit en
    Octobre 2006
    Messages
    587
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Octobre 2006
    Messages : 587
    Par défaut
    SQL Server ne base pas sur les noms des paramètres pour déterminer leur ordre, par contre certains autres SGBDR si.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. La masque de saisie pour les requêtes SQL
    Par Glauben dans le forum Général Java
    Réponses: 0
    Dernier message: 31/05/2011, 23h49
  2. Réponses: 6
    Dernier message: 14/12/2007, 23h26
  3. [SQL-SEVER2005] Gestion des erreurs pour les requêtes
    Par eagleleader dans le forum MS SQL Server
    Réponses: 22
    Dernier message: 16/10/2007, 09h59
  4. Réponses: 2
    Dernier message: 28/02/2007, 13h13
  5. [SQL] Sprintf ou concaténation pour créer les requêtes SQL?
    Par EvilAngel dans le forum PHP & Base de données
    Réponses: 5
    Dernier message: 15/09/2006, 17h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo