Requête SQL qui ne modifie pas la DB [Résolu]

[bobbely]

Salut à tous,

Je suis en train de développé une application WinForm en C# qui agit avec une base de donnée SQL Server CE. Celle-ci possède 3 tables, et j'ai un soucis avec avec une requête SQL qui n'effectue pas la demande alors que le compilateur (Visual C# 2010 Express) ne me signale aucune erreur. La table en question se nomme "User" et présente les colonnes "ID" (en auto-incrémentation et de valeur initiale 1), "Pseudo" et "Password".

Voici le code qui pose problème :

Code :

User AddUser = new User(textBoxPseudo.Text, textBoxPassword1.Text);

Et voici le code de ma classe :

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
public class User
    {
        public int ID;
        public string Pseudo;
        public string Password;
 
        public User(string pseudo, string password)
        {
            Pseudo = pseudo;
            Password = password;
            InsertUser();
        }
 
        private void InsertUser()
        {
            string strReq = "INSERT INTO [User] (Pseudo, Password) VALUES ('" + Pseudo + "','" + Password + "')";
 
            SqlCeConnection oConnection = new SqlCeConnection("Data Source=|DataDirectory|\\MyDatabase#1.sdf");
            SqlCeCommand Command = new SqlCeCommand(strReq, oConnection);
            oConnection.Open();
            Command.ExecuteNonQuery();
 
            oConnection.Close();
        }
    }

J'ai essayé en mode debug et j'arrive bien à une strReq style :

Code :

"INSERT INTO [User] (Pseudo, Password) VALUES ('monPseudo','monPassword')"

J'ai essayé d'envoyer la même requête via la commande "Nouvelle requête" proposée dans le compilateur et cela a bien ajouté une ligne à ma table ... Pouvez-vous m'aider à trouver la solution à mon problème?

[punkoff]

bonjour,

Ceci n'est donc pas un problème SQL mais bien un problème C#

Demandez à ce que l'on déplace votre poste ?

[bobbely]

Je ne crois pas que ce soit un problème en C# car le code ne rencontre pas de soucis, j'ai fait exactement la même procédure avec un autre objet (s'intégrant dans une autre table de la base) et je n'ai pas eu de soucis. De plus, le projet ne devrait pas compiler si c'était un soucis en C#, j'avais hésité à poser la question dans le forum C# mais j'en ai déduit que cela concernait plutôt le SQL.

[CinePhil]

Code :

"INSERT INTO [User] (Pseudo, Password) VALUES ('monPseudo','monPassword')"

Pourquoi avoir mis le nom de la table entre crochets ?

Code :

Command.ExecuteNonQuery();

Je ne connais pas C# mais ceci me laisse à penser que le programme s'attend à autre chose qu'une requête écrite en SQL natif ; un truc du genre saloperie de pseudo SQL inutilement compliqué des ORM.

[bobbely]

Finalement c'était un problème avec ma base de donnée, j'ai trouvé la solution en changeant ma ConnectionString en dur pour être sûr de manipuler la bonne DB.

[iberserk]

Pourquoi avoir mis le nom de la table entre crochets ?

User est un mot clé...

[Bluedeep]

Envoyé par CinePhil

Je ne connais pas C# mais ceci me laisse à penser que le programme s'attend à autre chose qu'une requête écrite en SQL natif ; un truc du genre saloperie de pseudo SQL inutilement compliqué des ORM.

Non, et ce code ne fait pas appel à un ORM, mais attaque une base SSCE directement via ADO.NET.
Et ExecuteNonQuery est la bonne méthode d'exécution de requête dès lors qu'il ne s'agit pas d'un 'SELECT'.

[Waldar]

J'aurai dit que la bonne méthode pour ce besoin est l'exécution d'une procédure stockée.

C'est le niveau 0 de la protection contre le SQL Injection !

[Bluedeep]

Envoyé par Waldar

C'est le niveau 0 de la protection contre le SQL Injection !

Pour une requête d'insertion simple tel que celle présentée, l'utilisation des requêtes paramètrées protège très bien contre l'injection SQL (ce qui n'est pas fait ici, au demeurant).

De plus, la base utilisée ici est SSCE, base "in-process" (l'objet de connexion utilisé est sans ambigüité) qui ne supporte pas les PS.