Discussion :

[fafa1107]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[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é

[mactwist69]

Lol, quand tu fais une boucle For :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[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.

[mactwist69]

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

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

[Sankasssss]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[Kropernic]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[mactwist69]

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.

[Kropernic]

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.

- 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 ?

- 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.

- 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.

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 ?

[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.

[Kropernic]

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

J'ai presque pas perdu ma journée alors

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...

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...