Problème insertion dans BDD sql server

Version imprimable

Bonjour,
Je suis en train de developper une caisse enregistreuse avec sauvegarde dans une BDD, mon problème est que lorsque j'ai plusieurs insertions à faire de suite dans une table je n'en ai qu'une sur deux au mieux qui se fait et je ne comprend pas pourquoi, voila le bout de code concerné

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 Dim Table As String
            Dim j As Integer
            For j = 1 To i
                Table = GroupBox2.Controls("Produit" & j).Text
                Requete = "Insert into " & Table & "(Quantite, Montant, Id_Client,Date) values ('" & CInt(GroupBox2.Controls("Qte" & j).Text) & "', '" & GroupBox2.Controls("Total" & j).Text.Replace(",", ".") & "', '3',CURRENT_TIMESTAMP) "
                Commande = New SqlCommand(Requete, Connexion)
                Try
                    Commande.ExecuteNonQuery()
 
                Catch ex As Exception
                    Adress.Text = "requete echouéee"
                End Try
                j = j + 1
            Next

Merci d'avance de votre aide

21/07/2015, 15h03
Invité

Je ne vois pas comment on pourrait te répondre, tu ne nous mets pas les structures des tables et les requêtes qui foirent :?
Peut-être que si tu mets le message d'erreur que tu obtiens, cela nous aiderait.
21/07/2015, 15h14
fafa1107

la requete qui foire est celle qui est dans la boucle a la ligne 5, et les tables sont multiples d'ou la variable "table" dans la requete mais elles ont ttes la meme structure un champ id(indexé+autoincrementé), un id_clint en int, un date en datetime,un quantite en int et enfin un montant en decimal.
Si je veut faire plusieurs insertion dans la mm table par exemple 8 insertion je n'ai que l'insertion 1 , 3 , 5, et 7 defectué
21/07/2015, 16h39
mactwist69

Lol, quand tu fais une boucle For :

Code:

For i=0 to 100

Il va incrémenter tout seul le i, au niveau du next...

Donc si tu ajoutes en plus un i=i+1 en fin de boucle... ben tu sautes une lignes... :aie:
21/07/2015, 18h21
fafa1107

et oui je ne le savait pas que l incrementation etait automatique(j'avais plus l'habitude du php ou on met le i++ dans le for).
desole.:scarymov:
22/07/2015, 08h58
mactwist69

Pour une boucle While, c'est toujours le cas...

Mais pour le For-Next ou For-Each, pas besoin....

Bonjour,

il faut éviter de concaténer une instruction SQL comme :

Code:

Requete = "Insert into " & Table & "(Quantite, Montant, Id_Client,Date) values ('" & CInt(GroupBox2.Controls("Qte" & j).Text) & "', '" & GroupBox2.Controls("Total" & j).Text.Replace(",", ".") & "', '3',CURRENT_TIMESTAMP) "

Il est en effet préférable d'utiliser les requêtes paramétrées comme ceci :
Code:

1 2 3 Requete = "Insert into " & Table & "(Quantite, Montant, Id_Client,Date) values ( @Qte , @Total, '3',CURRENT_TIMESTAMP) " Commande.Parameters.Add("@Qte", SqlDbType.VarChar).Value = GroupBox2.Controls("Qte" & j).Text Commande.Parameters.Add("@Total", SqlDbType.VarChar).Value = GroupBox2.Controls("Total" & j).Text.Replace(",", ".")
pour éviter un tas de problèmes comme l'injection SQL.
Voir le tuto : .Net, SQL Server, et les requêtes paramétrées (VB.Net) de webman

Autre point, les champs de la BD sont de type alphanumérique pour stoker des nombres?

Citation:
Envoyé par Sankasssss
Bonjour,

il faut éviter de concaténer une instruction SQL comme :

Code:

Requete = "Insert into " & Table & "(Quantite, Montant, Id_Client,Date) values ('" & CInt(GroupBox2.Controls("Qte" & j).Text) & "', '" & GroupBox2.Controls("Total" & j).Text.Replace(",", ".") & "', '3',CURRENT_TIMESTAMP) "

Il est en effet préférable d'utiliser les requêtes paramétrées comme ceci :
Code:

1 2 3 Requete = "Insert into " & Table & "(Quantite, Montant, Id_Client,Date) values ( @Qte , @Total, '3',CURRENT_TIMESTAMP) " Commande.Parameters.Add("@Qte", SqlDbType.VarChar).Value = GroupBox2.Controls("Qte" & j).Text Commande.Parameters.Add("@Total", SqlDbType.VarChar).Value = GroupBox2.Controls("Total" & j).Text.Replace(",", ".")
pour éviter un tas de problèmes comme l'injection SQL.
Voir le tuto : .Net, SQL Server, et les requêtes paramétrées (VB.Net) de webman

Autre point, les champs de la BD sont de type alphanumérique pour stoker des nombres?
Pour compléter, j'ajouterais que quitte à utiliser un vrai SGDB comme sql server, autant utiliser des procédures stockées et y déporter toutes les requêtes que vous écrivez actuellement dans votre application. Cela aura pour bienfait de vous éviter de devoir recompiler si vous devez effectuer une maintenance mineure sur la DB mais qui nécessite la modification des requêtes. Seule les procédures stockées impactées devront être mise à jour.

22/07/2015, 13h46
mactwist69

Citation:

Envoyé par Kropernic

Pour compléter, j'ajouterais que quitte à utiliser un vrai SGDB comme sql server, autant utiliser des procédures stockées et y déporter toutes les requêtes que vous écrivez actuellement dans votre application. Cela aura pour bienfait de vous éviter de devoir recompiler si vous devez effectuer une maintenance mineure sur la DB mais qui nécessite la modification des requêtes. Seule les procédures stockées impactées devront être mise à jour.

Il faut voir les inconvénients de cette solution, je vais me faire l'avocat de l'accusation :

- La gestion des erreurs et des retours sont plus pénibles... (variable in/out, et pour les erreurs aussi dans des variables ?)

- Si il s'agit d'une solution mutli-SGBD... ou même si on souhaite changer de SGBD... Il va falloir tout réécrire, et écrire des procédures stockées est quand même plus pénible que du code. (surtout si il s'agit d'une solution n'tiers qui possède une couche d'accès aux données, prévu pour le multi-sgbd)

- Si l'application se trouve chez plusieurs client... Ca me paraît moins compliqué de recompiler que de passer sur les SGBD de tous les clients... en faisant en sorte que tous soit au même niveaux de mise à jour etc... Devoir comparer le codes des procédures stockés ne sera pas non plus très easy.

- Pas non plus de numéro de version etc...

Je pense que ça peut être intéressant si c'est prévu des le début, avec du code automatique dans un périmètre bien délimité.
Mais sur des applications polyvalentes... je pense que ça complique les choses.
22/07/2015, 14h35
Kropernic

Citation:

Envoyé par mactwist69

Il faut voir les inconvénients de cette solution, je vais me faire l'avocat de l'accusation :

J'avoue volontiers que je suis un enthousiaste des procédures stockées et j'oublie facilement que, comme avec tout, il y a les pour et les contres ^^.
Et faut dire aussi que je développe uniquement en interne. Donc rien à mettre à jour chez un client distant. Ca doit grandement aider à l'utilisation et orienter mon point de vue aussi.

Citation:

Envoyé par mactwist69

- La gestion des erreurs et des retours sont plus pénibles... (variable in/out, et pour les erreurs aussi dans des variables ?)

Les classes de System.Data.SqlClient retourne le code d'erreur que sql server retournerait si le code de la requête était dans le programme. Quelle différence ?

Citation:

Envoyé par mactwist69

- Si il s'agit d'une solution mutli-SGBD... ou même si on souhaite changer de SGBD... Il va falloir tout réécrire, et écrire des procédures stockées est quand même plus pénible que du code. (surtout si il s'agit d'une solution n'tiers qui possède une couche d'accès aux données, prévu pour le multi-sgbd)

Surtout s'il s'agit d'une solution n tiers avec couche d'accès aux données, je te garantis qu'il est plus facile de travailler avec le code sql dans la DB. Je travaille de cette manière et si demain on me dit qu'on décide de tout basculer sur Oracle par exemple, je n'ai qu'à remplacer les classes de System.Data.SqlClient par l'équivalent pour Oracle. Ceci à condition bien sûr d'utiliser du code sql normalisé et pas propre au SGDB (du t-sql pour sql server ou du pl sql (si mes souvenirs sont bons) pour oracle pour ne citer qu'eux). Dans ce cas, il n'y a qu'à scripter les objets et faire tourner les scripts sur le nouveau sgdb et c'est fini. Ca fait quelques choses comme une dizaine de clics max.

Et puis, mais ça c'est un goût personnel, je préfère écrire du code sql. Cette manière ensembliste de travailler à quelques choses de...poétique.

Citation:

Envoyé par mactwist69

- Si l'application se trouve chez plusieurs client... Ca me paraît moins compliqué de recompiler que de passer sur les SGBD de tous les clients... en faisant en sorte que tous soit au même niveaux de mise à jour etc... Devoir comparer le codes des procédures stockés ne sera pas non plus très easy.

- Pas non plus de numéro de version etc...

Là, je pense que tu touches 2 points importants. Si l'application et la DB sont tous deux chez le client, alors je pense qu'il faut bien mettre en balance les coûts d'application d'un patch sur l'application ou d'exécution d'un script sql pour mettre à jour la DB.

Citation:

Envoyé par mactwist69

Je pense que ça peut être intéressant si c'est prévu des le début, avec du code automatique dans un périmètre bien délimité.
Mais sur des applications polyvalentes... je pense que ça complique les choses.

Qu'entends-tu par application polyvalentes ?
22/07/2015, 15h06
mactwist69

Pas mal, tu m'as presque convaincus du bien fondé.

A part, que je n'aime pas trop codé en sql... Je trouve plus poétique le code, avec de belles classes... lol
(le SQL c'est plat...)

Sinon part polyvalent, je parlais justement d'une solution que tu développes pour n clients, sur n sgbd différents etc.
Et là le versionning est très très très important.

Mais bon. il semble qu'il existe des solutions à tout.
22/07/2015, 15h16
Kropernic

Citation:

Envoyé par mactwist69

Pas mal, tu m'as presque convaincus du bien fondé.

J'ai presque pas perdu ma journée alors :aie:

Citation:

Envoyé par mactwist69

A part, que je n'aime pas trop codé en sql... Je trouve plus poétique le code, avec de belles classes... lol
(le SQL c'est plat...)

Les goûts et les couleurs...

Citation:

Envoyé par mactwist69

Sinon part polyvalent, je parlais justement d'une solution que tu développes pour n clients, sur n sgbd différents etc.
Et là le versionning est très très très important.

Mais bon. il semble qu'il existe des solutions à tout.

Il existe en effet des solutions de versionning pour le code sql. Perso, nous n'en utilisons pas. On a ça pour le code .net mais ça sert plus à faire des merges (quand on est plusieurs sur un projet car pour le moment, j'suis le seul du service...) qu'à vraiment récupérer des versions antérieures...