For i =3D 0 To CountFields - 1
aStr =3D "Le champ " & CopieChaine(myFields(i).name) & "
est du type " & _
myFields(i).type
ListBox1.AddItem (aStr)
Next
End If
mysql_free_result (pMyRES)
End If
End If
End Sub
tout fonctionne correctement mais lorsque je veux modifier cette
ligne :
If (mysql_query(pMySQL, "select nom from pet where prenom =3D 'JACQUES'
") =3D 0) Then
Par
If (mysql_query(pMySQL, "select nom from pet where prenom =3D" & prenom)
=3D 0) Then
ca ne fonctionne plus ... (en mode pas =E0 pas il y a pas de probleme,
prenom =3D JACQUES)
Tout d'abord, merci du retour d'info, c'est toujours agréable :-)
Pour conclure, voici un conseil général, valable pour tous les cas ou l'on utilise des requêtes SQL dans un programme, VB ou autre:
C'est une bonne pratique que de créer les statements SQL dans une variable, afin de pouvoir les afficher si nécessaire.
Voici par exemple ton cas:
Dim sql_statement As String
sql_statement = ""
sql_statement = "SELECT nom FROM pet WHERE prenom ='" & prenom & "'"
If mysql_query(pMySQL, sql_statement) = 0 Then ' tout va bien ' suite du code Else szErr = "Erreur lors de l'exécution de la requete " & vbCrLf szErr = szErr & sql_statemeet MsgBox szErr, vbExclamation, "Erreur SQL" End If
En faisant comme ceci, tu aurais probablement tout de suite vu ton erreur (l'oubli des simples quotes dans ton cas).
De plus et d'une façon générale, on a toujours intérêt à adopter ce style de codage, qui permet un débugage aisé et efficace.
Enfin ce type de code peut tout à fait rester dans le code de l'application finale, ne serait ce que pour faire le logging des erreurs.
J'attire ton attention sur le fait que si la variable prénom est entrée via une texte box, il est très simple de faire crasher ton programme en mettant tout simplement une quote dans le nom du champ ...
Voir à ce sujet : http://faq.vb.free.fr/index.php?question2
Voila, espérant que ce petit truc/conseil puisse t'être utile :-)
Tout d'abord, merci du retour d'info, c'est toujours agréable :-)
Pour conclure, voici un conseil général, valable pour tous les
cas ou l'on utilise des requêtes SQL dans un programme, VB ou
autre:
C'est une bonne pratique que de créer les statements SQL dans
une variable, afin de pouvoir les afficher si nécessaire.
Voici par exemple ton cas:
Dim sql_statement As String
sql_statement = ""
sql_statement = "SELECT nom FROM pet WHERE prenom ='" & prenom & "'"
If mysql_query(pMySQL, sql_statement) = 0 Then
' tout va bien
' suite du code
Else
szErr = "Erreur lors de l'exécution de la requete " & vbCrLf
szErr = szErr & sql_statemeet
MsgBox szErr, vbExclamation, "Erreur SQL"
End If
En faisant comme ceci, tu aurais probablement tout de suite vu ton erreur
(l'oubli des simples quotes dans ton cas).
De plus et d'une façon générale, on a toujours intérêt à adopter ce style
de codage, qui permet un débugage aisé et efficace.
Enfin ce type de code peut tout à fait rester dans le code de l'application
finale, ne serait ce que pour faire le logging des erreurs.
J'attire ton attention sur le fait que si la variable prénom est entrée via
une
texte box, il est très simple de faire crasher ton programme en mettant tout
simplement
une quote dans le nom du champ ...
Voir à ce sujet : http://faq.vb.free.fr/index.php?question2
Voila, espérant que ce petit truc/conseil puisse t'être utile :-)
Tout d'abord, merci du retour d'info, c'est toujours agréable :-)
Pour conclure, voici un conseil général, valable pour tous les cas ou l'on utilise des requêtes SQL dans un programme, VB ou autre:
C'est une bonne pratique que de créer les statements SQL dans une variable, afin de pouvoir les afficher si nécessaire.
Voici par exemple ton cas:
Dim sql_statement As String
sql_statement = ""
sql_statement = "SELECT nom FROM pet WHERE prenom ='" & prenom & "'"
If mysql_query(pMySQL, sql_statement) = 0 Then ' tout va bien ' suite du code Else szErr = "Erreur lors de l'exécution de la requete " & vbCrLf szErr = szErr & sql_statemeet MsgBox szErr, vbExclamation, "Erreur SQL" End If
En faisant comme ceci, tu aurais probablement tout de suite vu ton erreur (l'oubli des simples quotes dans ton cas).
De plus et d'une façon générale, on a toujours intérêt à adopter ce style de codage, qui permet un débugage aisé et efficace.
Enfin ce type de code peut tout à fait rester dans le code de l'application finale, ne serait ce que pour faire le logging des erreurs.
J'attire ton attention sur le fait que si la variable prénom est entrée via une texte box, il est très simple de faire crasher ton programme en mettant tout simplement une quote dans le nom du champ ...
Voir à ce sujet : http://faq.vb.free.fr/index.php?question2
Voila, espérant que ce petit truc/conseil puisse t'être utile :-)
Un petit grain de sel maintenant que Jean-Marc a répondu.
Dans une base où j'ai beaucoup de requêtes avec des guillemets, je trouve pratique d'avoir une fonction
Public Function G(argu As String) As String G = VBA.Chr$(34) + argu + VBA.Chr$(34) End Function
Ainsi, pas besoin de compter les guillemets quand on écrit
strSQL = strSQL + " WHERE prenom = " + G(champPrenom) strSQL = strSQL + " AND nom = " + G(champNom)
La syntaxe développée avec + et le préfixe VBA est conseillée qua nd on développe sous une version antique d'Access pour convertir dans différentes versions plus récentes.
Enfin bon, chacun voit midi à sa porte. Bien entendu, si on n'appelle l a fonction G (comme guillemets) qu'une fois dans la base, c'est moins intéressant, vu qu'il faudra le temps d'aller la lire pour savoir de quoi il retourne.
*
Un jour où cette question a été mise sur le tapis, quelqu'un m'a ra ppelé qu'il était plutôt conseillé d'utiliser des requêtes paramétré es, pour des raisons de sécurité. Mais à vrai dire, il me semble que ceci su ppose des appels à la base via Internet ou pour le moins un réseau, alors qu'une requête dynamique à partir du code de la base de données elle-même ne s'envisage pas vraiment de la même manière ?
Superman a écrit, le 10/07/2007 10:53 :
Bonjour,
J'utilise la fonction suivante pour lire dans une base de données :
Private Sub LitStructure(pMySQL As Long, prenom As String)
Dim pMyROW As Long, pMyRES As Long, pMyFields As Long, myFields() As MYSQL_FIELD Dim aStr As String, CountFields As Integer, i As Integer
If (mysql_query(pMySQL, "select nom from pet where prenom = 'JACQUES' ") = 0) Then
For i = 0 To CountFields - 1 aStr = "Le champ " & CopieChaine(myFields(i).name) & " est du type " & _ myFields(i).type ListBox1.AddItem (aStr) Next End If mysql_free_result (pMyRES) End If End If
End Sub
tout fonctionne correctement mais lorsque je veux modifier cette ligne : If (mysql_query(pMySQL, "select nom from pet where prenom = 'JACQUES' ") = 0) Then
Par
If (mysql_query(pMySQL, "select nom from pet where prenom =" & prenom ) = 0) Then
ca ne fonctionne plus ... (en mode pas à pas il y a pas de probleme, prenom = JACQUES)
Connaissez vous la raison ?
Merci
Bonjour,
Un petit grain de sel maintenant que Jean-Marc a répondu.
Dans une base où j'ai beaucoup de requêtes avec des guillemets, je
trouve pratique d'avoir une fonction
Public Function G(argu As String) As String
G = VBA.Chr$(34) + argu + VBA.Chr$(34)
End Function
Ainsi, pas besoin de compter les guillemets quand on écrit
strSQL = strSQL + " WHERE prenom = " + G(champPrenom)
strSQL = strSQL + " AND nom = " + G(champNom)
La syntaxe développée avec + et le préfixe VBA est conseillée qua nd on
développe sous une version antique d'Access pour convertir dans
différentes versions plus récentes.
Enfin bon, chacun voit midi à sa porte. Bien entendu, si on n'appelle l a
fonction G (comme guillemets) qu'une fois dans la base, c'est moins
intéressant, vu qu'il faudra le temps d'aller la lire pour savoir de
quoi il retourne.
*
Un jour où cette question a été mise sur le tapis, quelqu'un m'a ra ppelé
qu'il était plutôt conseillé d'utiliser des requêtes paramétré es, pour
des raisons de sécurité. Mais à vrai dire, il me semble que ceci su ppose
des appels à la base via Internet ou pour le moins un réseau, alors
qu'une requête dynamique à partir du code de la base de données
elle-même ne s'envisage pas vraiment de la même manière ?
Superman a écrit, le 10/07/2007 10:53 :
Bonjour,
J'utilise la fonction suivante pour lire dans une base de données :
Private Sub LitStructure(pMySQL As Long, prenom As String)
Dim pMyROW As Long, pMyRES As Long, pMyFields As Long, myFields() As
MYSQL_FIELD
Dim aStr As String, CountFields As Integer, i As Integer
If (mysql_query(pMySQL, "select nom from pet where prenom = 'JACQUES'
") = 0) Then
For i = 0 To CountFields - 1
aStr = "Le champ " & CopieChaine(myFields(i).name) & "
est du type " & _
myFields(i).type
ListBox1.AddItem (aStr)
Next
End If
mysql_free_result (pMyRES)
End If
End If
End Sub
tout fonctionne correctement mais lorsque je veux modifier cette
ligne :
If (mysql_query(pMySQL, "select nom from pet where prenom = 'JACQUES'
") = 0) Then
Par
If (mysql_query(pMySQL, "select nom from pet where prenom =" & prenom )
= 0) Then
ca ne fonctionne plus ... (en mode pas à pas il y a pas de probleme,
prenom = JACQUES)
Un petit grain de sel maintenant que Jean-Marc a répondu.
Dans une base où j'ai beaucoup de requêtes avec des guillemets, je trouve pratique d'avoir une fonction
Public Function G(argu As String) As String G = VBA.Chr$(34) + argu + VBA.Chr$(34) End Function
Ainsi, pas besoin de compter les guillemets quand on écrit
strSQL = strSQL + " WHERE prenom = " + G(champPrenom) strSQL = strSQL + " AND nom = " + G(champNom)
La syntaxe développée avec + et le préfixe VBA est conseillée qua nd on développe sous une version antique d'Access pour convertir dans différentes versions plus récentes.
Enfin bon, chacun voit midi à sa porte. Bien entendu, si on n'appelle l a fonction G (comme guillemets) qu'une fois dans la base, c'est moins intéressant, vu qu'il faudra le temps d'aller la lire pour savoir de quoi il retourne.
*
Un jour où cette question a été mise sur le tapis, quelqu'un m'a ra ppelé qu'il était plutôt conseillé d'utiliser des requêtes paramétré es, pour des raisons de sécurité. Mais à vrai dire, il me semble que ceci su ppose des appels à la base via Internet ou pour le moins un réseau, alors qu'une requête dynamique à partir du code de la base de données elle-même ne s'envisage pas vraiment de la même manière ?
Superman a écrit, le 10/07/2007 10:53 :
Bonjour,
J'utilise la fonction suivante pour lire dans une base de données :
Private Sub LitStructure(pMySQL As Long, prenom As String)
Dim pMyROW As Long, pMyRES As Long, pMyFields As Long, myFields() As MYSQL_FIELD Dim aStr As String, CountFields As Integer, i As Integer
If (mysql_query(pMySQL, "select nom from pet where prenom = 'JACQUES' ") = 0) Then
For i = 0 To CountFields - 1 aStr = "Le champ " & CopieChaine(myFields(i).name) & " est du type " & _ myFields(i).type ListBox1.AddItem (aStr) Next End If mysql_free_result (pMyRES) End If End If
End Sub
tout fonctionne correctement mais lorsque je veux modifier cette ligne : If (mysql_query(pMySQL, "select nom from pet where prenom = 'JACQUES' ") = 0) Then
Par
If (mysql_query(pMySQL, "select nom from pet where prenom =" & prenom ) = 0) Then
ca ne fonctionne plus ... (en mode pas à pas il y a pas de probleme, prenom = JACQUES)
Connaissez vous la raison ?
Merci
parci
On Wed, 11 Jul 2007 21:18:31 +0200, Gloops wrote:
Public Function G(argu As String) As String G = VBA.Chr$(34) + argu + VBA.Chr$(34) End Function
Ainsi, pas besoin de compter les guillemets quand on écrit
strSQL = strSQL + " WHERE prenom = " + G(champPrenom) strSQL = strSQL + " AND nom = " + G(champNom)
La syntaxe développée avec + et le préfixe VBA est conseillée quand on développe sous une version antique d'Access pour convertir dans différentes versions plus récentes.
Enfin bon, chacun voit midi à sa porte. Bien entendu, si on n'appelle la fonction G (comme guillemets) qu'une fois dans la base, c'est moins intéressant, vu qu'il faudra le temps d'aller la lire pour savoir de quoi il retourne.
Ta fonction serait encore mieux si elle doublait les quotes éventuelles dans argu. Mais c'est très bien de faire une fonction pour ce genre de chose (sauf dans une optique vb agricole - quoique l'agriculture d'aujourd'hui a évoluée elle aussi).
*
Un jour où cette question a été mise sur le tapis, quelqu'un m'a rappelé qu'il était plutôt conseillé d'utiliser des requêtes paramétrées, pour des raisons de sécurité. Mais à vrai dire, il me semble que ceci suppose des appels à la base via Internet ou pour le moins un réseau, alors qu'une requête dynamique à partir du code de la base de données elle-même ne s'envisage pas vraiment de la même manière ?
Ce n'est pas une question de réseau, mais tu peux fixer des droits sur des requêtes paramètrées, et donc contrôler les actions possibles en fonction des utilisateurs.
D'autre part, en cas d'évolutions , ça peut être plus léger (seule la requête est à modifier si le code est suffisamment générique ensuite).
Ceci dit, avec ADO et Access, il y a un inconvénient aux requêtes paramètrées : le recordset renvoyé est obligatoirement en lecture seule (du moins, j'ai pas trouvé comment faire autrement - si l'un de vous sait d'ailleurs).
On Wed, 11 Jul 2007 21:18:31 +0200, Gloops <gloops@niark.invalid>
wrote:
Public Function G(argu As String) As String
G = VBA.Chr$(34) + argu + VBA.Chr$(34)
End Function
Ainsi, pas besoin de compter les guillemets quand on écrit
strSQL = strSQL + " WHERE prenom = " + G(champPrenom)
strSQL = strSQL + " AND nom = " + G(champNom)
La syntaxe développée avec + et le préfixe VBA est conseillée quand on
développe sous une version antique d'Access pour convertir dans
différentes versions plus récentes.
Enfin bon, chacun voit midi à sa porte. Bien entendu, si on n'appelle la
fonction G (comme guillemets) qu'une fois dans la base, c'est moins
intéressant, vu qu'il faudra le temps d'aller la lire pour savoir de
quoi il retourne.
Ta fonction serait encore mieux si elle doublait les quotes
éventuelles dans argu. Mais c'est très bien de faire une fonction pour
ce genre de chose (sauf dans une optique vb agricole - quoique
l'agriculture d'aujourd'hui a évoluée elle aussi).
*
Un jour où cette question a été mise sur le tapis, quelqu'un m'a rappelé
qu'il était plutôt conseillé d'utiliser des requêtes paramétrées, pour
des raisons de sécurité. Mais à vrai dire, il me semble que ceci suppose
des appels à la base via Internet ou pour le moins un réseau, alors
qu'une requête dynamique à partir du code de la base de données
elle-même ne s'envisage pas vraiment de la même manière ?
Ce n'est pas une question de réseau, mais tu peux fixer des droits sur
des requêtes paramètrées, et donc contrôler les actions possibles en
fonction des utilisateurs.
D'autre part, en cas d'évolutions , ça peut être plus léger (seule la
requête est à modifier si le code est suffisamment générique ensuite).
Ceci dit, avec ADO et Access, il y a un inconvénient aux requêtes
paramètrées : le recordset renvoyé est obligatoirement en lecture
seule (du moins, j'ai pas trouvé comment faire autrement - si l'un de
vous sait d'ailleurs).
Public Function G(argu As String) As String G = VBA.Chr$(34) + argu + VBA.Chr$(34) End Function
Ainsi, pas besoin de compter les guillemets quand on écrit
strSQL = strSQL + " WHERE prenom = " + G(champPrenom) strSQL = strSQL + " AND nom = " + G(champNom)
La syntaxe développée avec + et le préfixe VBA est conseillée quand on développe sous une version antique d'Access pour convertir dans différentes versions plus récentes.
Enfin bon, chacun voit midi à sa porte. Bien entendu, si on n'appelle la fonction G (comme guillemets) qu'une fois dans la base, c'est moins intéressant, vu qu'il faudra le temps d'aller la lire pour savoir de quoi il retourne.
Ta fonction serait encore mieux si elle doublait les quotes éventuelles dans argu. Mais c'est très bien de faire une fonction pour ce genre de chose (sauf dans une optique vb agricole - quoique l'agriculture d'aujourd'hui a évoluée elle aussi).
*
Un jour où cette question a été mise sur le tapis, quelqu'un m'a rappelé qu'il était plutôt conseillé d'utiliser des requêtes paramétrées, pour des raisons de sécurité. Mais à vrai dire, il me semble que ceci suppose des appels à la base via Internet ou pour le moins un réseau, alors qu'une requête dynamique à partir du code de la base de données elle-même ne s'envisage pas vraiment de la même manière ?
Ce n'est pas une question de réseau, mais tu peux fixer des droits sur des requêtes paramètrées, et donc contrôler les actions possibles en fonction des utilisateurs.
D'autre part, en cas d'évolutions , ça peut être plus léger (seule la requête est à modifier si le code est suffisamment générique ensuite).
Ceci dit, avec ADO et Access, il y a un inconvénient aux requêtes paramètrées : le recordset renvoyé est obligatoirement en lecture seule (du moins, j'ai pas trouvé comment faire autrement - si l'un de vous sait d'ailleurs).
