suite au problème de simple côte et double côte en SQL
je croyais avoir résolu le problème.
Quand ma variable à utiliser dans le SQL contient une
simple côte, je l'encradre de double double côte et quand
elle contient une double côte je fais un replace.
Mais je viens de me heurter à un nouveau problème :
je sauve des mots de passe dans une base Access et je
les crypte pour que seul mon appli puisse les lire. Cela
marche bien sauf si le mot de passe crypté contient à la
fois une simple ET une double côte.
Là, cela plante ADO et impossible d'utiliser le replace.
désolé de rajouter un message à une liste déjà longue, mais je ne comprends pas vraiment l'intérêt de passer par la collection paramètres lorsque l'on n'y est pas obligé (cas des procédures stockées en particulier).
Je pense que nous ne parlons pas de la même chose. Le cas des procédures stockées est identique pour moi et même plus intuitif car une procédure stockée possède des paramètres explicites.
Pour le problème exposé, j'utiliserais un recordset en affectant directement dans la zone concernée :
Set MonRecordset = Connexion.execute(SELECT CleCrypto FROM Table WHERE ...)
Et bien voilà : que mets-tu après le WHERE ? C'est là qu'il faut effectuer des manipulations si on veut faire de la concaténation, alors que l'utilisation d'un paramètre est, amha, beaucoup plus fiable. Mais reprend l'exemple que j'ai passé à Daniel.
MonRecordset.fields(0).Value = CleCrypto
Oui, dans ce cas tu utilises bien des fonctionnalités analogues à celles d'un paramètre. Il est effectivement inutile dans ce cas de faire des substitutions dans la chaîne. C'est pris en charge par l'objet recordset au même titre qu'un paramètre le prend en charge dans l'objet Command. Un recordset, ce n'est plus ou moins qu'une encapsulation de 4 requêtes (select, insert, delete, update), un schéma et un jeu de valeurs. Est-ce que pour autant tu préfères écrire :
cmd.text = "update Table set CleCrypto='" & fonctionCompliquée(CleCrypto) & "' where id=" & fonctionPlusSimple(Id) & ";" cmd.Execute
C'est exactement (ou à peu près) ce qui se passe quand on appelle la méthode Update. La sélection de la ligne altérée porte, je crois, non seulement sur la clé, mais également sur les autres colonnes avec leurs anciennes valeurs. Ceci pour être averti si la ligne source a été modifiée entre le moment où on l'a chargée et le moment où on la met à jour. Mais il me semble que ce comportement peut-être modifié.
J'espère que je suis plus clair maintenant :-)
-- Fred mail : foleide at free.fr
Dans : news:CFE39EFA-2EA5-444A-9E9E-90461EFF076E@microsoft.com,
SAISAS disait :
Bonjour,
Bonsoir,
désolé de rajouter un message à une liste déjà longue, mais je ne
comprends pas vraiment l'intérêt de passer par la collection
paramètres lorsque l'on n'y est pas obligé (cas des procédures
stockées en particulier).
Je pense que nous ne parlons pas de la même chose.
Le cas des procédures stockées est identique pour moi et même plus
intuitif car une procédure stockée possède des paramètres explicites.
Pour le problème exposé, j'utiliserais un recordset en affectant
directement dans la zone concernée :
Set MonRecordset = Connexion.execute(SELECT CleCrypto FROM Table
WHERE ...)
Et bien voilà : que mets-tu après le WHERE ?
C'est là qu'il faut effectuer des manipulations si on veut faire de la
concaténation, alors que l'utilisation d'un paramètre est, amha,
beaucoup plus fiable.
Mais reprend l'exemple que j'ai passé à Daniel.
MonRecordset.fields(0).Value = CleCrypto
Oui, dans ce cas tu utilises bien des fonctionnalités analogues à celles
d'un paramètre.
Il est effectivement inutile dans ce cas de faire des substitutions dans
la chaîne.
C'est pris en charge par l'objet recordset au même titre qu'un paramètre
le prend en charge dans l'objet Command.
Un recordset, ce n'est plus ou moins qu'une encapsulation de 4 requêtes
(select, insert, delete, update), un schéma et un jeu de valeurs.
Est-ce que pour autant tu préfères écrire :
cmd.text = "update Table set CleCrypto='" &
fonctionCompliquée(CleCrypto) & "' where id=" & fonctionPlusSimple(Id) &
";"
cmd.Execute
C'est exactement (ou à peu près) ce qui se passe quand on appelle la
méthode Update.
La sélection de la ligne altérée porte, je crois, non seulement sur la
clé, mais également sur les autres colonnes avec leurs anciennes
valeurs. Ceci pour être averti si la ligne source a été modifiée entre
le moment où on l'a chargée et le moment où on la met à jour.
Mais il me semble que ce comportement peut-être modifié.
désolé de rajouter un message à une liste déjà longue, mais je ne comprends pas vraiment l'intérêt de passer par la collection paramètres lorsque l'on n'y est pas obligé (cas des procédures stockées en particulier).
Je pense que nous ne parlons pas de la même chose. Le cas des procédures stockées est identique pour moi et même plus intuitif car une procédure stockée possède des paramètres explicites.
Pour le problème exposé, j'utiliserais un recordset en affectant directement dans la zone concernée :
Set MonRecordset = Connexion.execute(SELECT CleCrypto FROM Table WHERE ...)
Et bien voilà : que mets-tu après le WHERE ? C'est là qu'il faut effectuer des manipulations si on veut faire de la concaténation, alors que l'utilisation d'un paramètre est, amha, beaucoup plus fiable. Mais reprend l'exemple que j'ai passé à Daniel.
MonRecordset.fields(0).Value = CleCrypto
Oui, dans ce cas tu utilises bien des fonctionnalités analogues à celles d'un paramètre. Il est effectivement inutile dans ce cas de faire des substitutions dans la chaîne. C'est pris en charge par l'objet recordset au même titre qu'un paramètre le prend en charge dans l'objet Command. Un recordset, ce n'est plus ou moins qu'une encapsulation de 4 requêtes (select, insert, delete, update), un schéma et un jeu de valeurs. Est-ce que pour autant tu préfères écrire :
cmd.text = "update Table set CleCrypto='" & fonctionCompliquée(CleCrypto) & "' where id=" & fonctionPlusSimple(Id) & ";" cmd.Execute
C'est exactement (ou à peu près) ce qui se passe quand on appelle la méthode Update. La sélection de la ligne altérée porte, je crois, non seulement sur la clé, mais également sur les autres colonnes avec leurs anciennes valeurs. Ceci pour être averti si la ligne source a été modifiée entre le moment où on l'a chargée et le moment où on la met à jour. Mais il me semble que ce comportement peut-être modifié.
