Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gloops
Bonjour,
Il faudrait regarder la requête de plus près pour être catégoriqu e, mais j'aurais une très nette préférence pour la deuxième solution.
Si tu te livres régulièrement à ce genre de sport, tu vas vite t'apercevoir qu'il est avantageux d'automatiser un peu la chose.
Tu prépares la requête dans l'éditeur de requêtes d'Access, puis tu passes en mode SQL (grâce au bouton-liste en haut à gauche), tu copie s le code SQL de la requête, et tu le colles dans Word.
Tu places une marque de paragraphe à la fin de chaque ligne, et puis ensuite tu effectues un remplacement sur les marques de paragraphes pour placer chaque ligne entre guillemets et ajouter ce qu'il faut entre deux, dans ce style :
strSQL = "UPDATE tabTest SET tesParam1='alpha', " + _ "tesParam2=3 WHERE tesClef='laclef'"
C'est là que ça peut être intéressant d'automatiser, car cette co mmande de remplacement peut revenir assez régulièrement, donc une macro Word pour faire ça peut s'avérer pratique.
Une fois que tu en es là, ça devient assez facile de sortir le paramè tre voulu pour le lire dans une variable (note qu'il existe deux façons de couper les lignes, et que j'en change là) :
strSQL = "UPDATE tabTest SET tesParam1='"
Jusque là, pas de changement, l'intéressant arrive ensuite.
Là, j'ai chargé la syntaxe, car je suis habitué aux contraintes pou r une base développée en Access 95 qui doit tourner en Access 97 et 2000. S ur une version plus récente et sans perspective de migration, j'imagine qu'on peut se contenter de :
strSQL = strSQL + "tesParam2 = " & intParam2
et pour finir, en n'oubliant surtout pas l'espace (erreur très classiqu e dans ce genre d'exercice) :
strSQL = strSQL + " WHERE tesClef='laclef'"
Tu noteras la présence des apostrophes autour du premier paramètre, d e type caractère, et leur absence autour du deuxième, de type numériq ue.
Pour que l'exercice soit terminé, il reste encore à doubler les apostrophes dans le paramètre chaîne de caractères, puisqu'il est encadré d'apostrophes. La première ligne "intéressante" ci-dessus d evient :
En deuxième argument de Replace, une apostrophe, en troisième argumen t, deux apostrophes. Le préfixe VBA fait partie des habitudes que j'ai évoquées pour une migration 95/97.
Voilà, à la fin de ça, tu as la saisie disponible dans strParam (si c'est du texte) ou dans intParam2 (si c'est un nombre).
__________________________________ Jac a écrit, le 07/07/2008 17:29 :
Bonjour à tous,
j'ai une procédure évènementielle qui ouvre une requête paramè trée qui demande [Quel est le n° du département à afficher ?].
J'aurais besoin de récupérer la valeur saisie dans le paramètre d e la requête dans une variable du code vba afin de m'en servir un peu plus loin...
Est-ce possible ou dois-je poser la question en vba et affecter la réponse à la requête ? Mais dans les deux cas je ne vois pas trop comment faire...
Merci d'avance pour vos suggestions.
Jac
Bonjour,
Il faudrait regarder la requête de plus près pour être catégoriqu e, mais
j'aurais une très nette préférence pour la deuxième solution.
Si tu te livres régulièrement à ce genre de sport, tu vas vite
t'apercevoir qu'il est avantageux d'automatiser un peu la chose.
Tu prépares la requête dans l'éditeur de requêtes d'Access, puis tu
passes en mode SQL (grâce au bouton-liste en haut à gauche), tu copie s
le code SQL de la requête, et tu le colles dans Word.
Tu places une marque de paragraphe à la fin de chaque ligne, et puis
ensuite tu effectues un remplacement sur les marques de paragraphes pour
placer chaque ligne entre guillemets et ajouter ce qu'il faut entre
deux, dans ce style :
strSQL = "UPDATE tabTest SET tesParam1='alpha', " + _
"tesParam2=3 WHERE tesClef='laclef'"
C'est là que ça peut être intéressant d'automatiser, car cette co mmande
de remplacement peut revenir assez régulièrement, donc une macro Word
pour faire ça peut s'avérer pratique.
Une fois que tu en es là, ça devient assez facile de sortir le paramè tre
voulu pour le lire dans une variable (note qu'il existe deux façons de
couper les lignes, et que j'en change là) :
strSQL = "UPDATE tabTest SET tesParam1='"
Jusque là, pas de changement, l'intéressant arrive ensuite.
Là, j'ai chargé la syntaxe, car je suis habitué aux contraintes pou r une
base développée en Access 95 qui doit tourner en Access 97 et 2000. S ur
une version plus récente et sans perspective de migration, j'imagine
qu'on peut se contenter de :
strSQL = strSQL + "tesParam2 = " & intParam2
et pour finir, en n'oubliant surtout pas l'espace (erreur très classiqu e
dans ce genre d'exercice) :
strSQL = strSQL + " WHERE tesClef='laclef'"
Tu noteras la présence des apostrophes autour du premier paramètre, d e
type caractère, et leur absence autour du deuxième, de type numériq ue.
Pour que l'exercice soit terminé, il reste encore à doubler les
apostrophes dans le paramètre chaîne de caractères, puisqu'il est
encadré d'apostrophes. La première ligne "intéressante" ci-dessus d evient :
En deuxième argument de Replace, une apostrophe, en troisième argumen t,
deux apostrophes. Le préfixe VBA fait partie des habitudes que j'ai
évoquées pour une migration 95/97.
Voilà, à la fin de ça, tu as la saisie disponible dans strParam (si
c'est du texte) ou dans intParam2 (si c'est un nombre).
__________________________________
Jac a écrit, le 07/07/2008 17:29 :
Bonjour à tous,
j'ai une procédure évènementielle qui ouvre une requête paramè trée qui
demande [Quel est le n° du département à afficher ?].
J'aurais besoin de récupérer la valeur saisie dans le paramètre d e la
requête dans une variable du code vba afin de m'en servir un peu plus
loin...
Est-ce possible ou dois-je poser la question en vba et affecter la
réponse à la requête ? Mais dans les deux cas je ne vois pas trop
comment faire...
Il faudrait regarder la requête de plus près pour être catégoriqu e, mais j'aurais une très nette préférence pour la deuxième solution.
Si tu te livres régulièrement à ce genre de sport, tu vas vite t'apercevoir qu'il est avantageux d'automatiser un peu la chose.
Tu prépares la requête dans l'éditeur de requêtes d'Access, puis tu passes en mode SQL (grâce au bouton-liste en haut à gauche), tu copie s le code SQL de la requête, et tu le colles dans Word.
Tu places une marque de paragraphe à la fin de chaque ligne, et puis ensuite tu effectues un remplacement sur les marques de paragraphes pour placer chaque ligne entre guillemets et ajouter ce qu'il faut entre deux, dans ce style :
strSQL = "UPDATE tabTest SET tesParam1='alpha', " + _ "tesParam2=3 WHERE tesClef='laclef'"
C'est là que ça peut être intéressant d'automatiser, car cette co mmande de remplacement peut revenir assez régulièrement, donc une macro Word pour faire ça peut s'avérer pratique.
Une fois que tu en es là, ça devient assez facile de sortir le paramè tre voulu pour le lire dans une variable (note qu'il existe deux façons de couper les lignes, et que j'en change là) :
strSQL = "UPDATE tabTest SET tesParam1='"
Jusque là, pas de changement, l'intéressant arrive ensuite.
Là, j'ai chargé la syntaxe, car je suis habitué aux contraintes pou r une base développée en Access 95 qui doit tourner en Access 97 et 2000. S ur une version plus récente et sans perspective de migration, j'imagine qu'on peut se contenter de :
strSQL = strSQL + "tesParam2 = " & intParam2
et pour finir, en n'oubliant surtout pas l'espace (erreur très classiqu e dans ce genre d'exercice) :
strSQL = strSQL + " WHERE tesClef='laclef'"
Tu noteras la présence des apostrophes autour du premier paramètre, d e type caractère, et leur absence autour du deuxième, de type numériq ue.
Pour que l'exercice soit terminé, il reste encore à doubler les apostrophes dans le paramètre chaîne de caractères, puisqu'il est encadré d'apostrophes. La première ligne "intéressante" ci-dessus d evient :
En deuxième argument de Replace, une apostrophe, en troisième argumen t, deux apostrophes. Le préfixe VBA fait partie des habitudes que j'ai évoquées pour une migration 95/97.
Voilà, à la fin de ça, tu as la saisie disponible dans strParam (si c'est du texte) ou dans intParam2 (si c'est un nombre).
__________________________________ Jac a écrit, le 07/07/2008 17:29 :
Bonjour à tous,
j'ai une procédure évènementielle qui ouvre une requête paramè trée qui demande [Quel est le n° du département à afficher ?].
J'aurais besoin de récupérer la valeur saisie dans le paramètre d e la requête dans une variable du code vba afin de m'en servir un peu plus loin...
Est-ce possible ou dois-je poser la question en vba et affecter la réponse à la requête ? Mais dans les deux cas je ne vois pas trop comment faire...
Merci d'avance pour vos suggestions.
Jac
3stone
Salut,
"Jac" | j'ai une procédure évènementielle qui ouvre une requête paramètrée qui | demande [Quel est le n° du département à afficher ?]. | | J'aurais besoin de récupérer la valeur saisie dans le paramètre de la | requête dans une variable du code vba afin de m'en servir un peu plus | loin... | | Est-ce possible ou dois-je poser la question en vba et affecter la | réponse à la requête ? Mais dans les deux cas je ne vois pas trop | comment faire...
Admettons que cette requête alimente un état...
Dans cet état, il suffit d'écrire comme source dans une zone de texte:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
"Jac"
| j'ai une procédure évènementielle qui ouvre une requête paramètrée qui
| demande [Quel est le n° du département à afficher ?].
|
| J'aurais besoin de récupérer la valeur saisie dans le paramètre de la
| requête dans une variable du code vba afin de m'en servir un peu plus
| loin...
|
| Est-ce possible ou dois-je poser la question en vba et affecter la
| réponse à la requête ? Mais dans les deux cas je ne vois pas trop
| comment faire...
Admettons que cette requête alimente un état...
Dans cet état, il suffit d'écrire comme source dans une zone de texte:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
"Jac" | j'ai une procédure évènementielle qui ouvre une requête paramètrée qui | demande [Quel est le n° du département à afficher ?]. | | J'aurais besoin de récupérer la valeur saisie dans le paramètre de la | requête dans une variable du code vba afin de m'en servir un peu plus | loin... | | Est-ce possible ou dois-je poser la question en vba et affecter la | réponse à la requête ? Mais dans les deux cas je ne vois pas trop | comment faire...
Admettons que cette requête alimente un état...
Dans cet état, il suffit d'écrire comme source dans une zone de texte:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
Dans cet état, il suffit d'écrire comme source dans une zone de tex te:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
Ah, et après, se référer au nom de la zone de texte ?
Oh, mais tu en as, des bonnes idées, toi :)
Dans les cas où ça s'applique, il faut y penser.
3stone
Salut Gloops,
"Gloops" 3stone a écrit, le 07/07/2008 20:40 :
Admettons que cette requête alimente un état...
Dans cet état, il suffit d'écrire comme source dans une zone de texte:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
| Ah, et après, se référer au nom de la zone de texte ? | | Oh, mais tu en as, des bonnes idées, toi :) | | Dans les cas où ça s'applique, il faut y penser.
Ce ne sont pas des idées ;-) Cela fonctionnait déjà avec Access97, voir avant...
Bien connaître la version que l'on utilise est plus productif que d'acheter la "dernière" version que l'on ne maîtrise pas ;-))
Dans cet état, il suffit d'écrire comme source dans une zone de texte:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
| Ah, et après, se référer au nom de la zone de texte ?
|
| Oh, mais tu en as, des bonnes idées, toi :)
|
| Dans les cas où ça s'applique, il faut y penser.
Ce ne sont pas des idées ;-)
Cela fonctionnait déjà avec Access97, voir avant...
Bien connaître la version que l'on utilise est plus productif que
d'acheter la "dernière" version que l'on ne maîtrise pas ;-))
Dans cet état, il suffit d'écrire comme source dans une zone de texte:
= [Quel est le n° du département à afficher ?]
en fait, la considérer comme un champ quelconque ;-)
| Ah, et après, se référer au nom de la zone de texte ? | | Oh, mais tu en as, des bonnes idées, toi :) | | Dans les cas où ça s'applique, il faut y penser.
Ce ne sont pas des idées ;-) Cela fonctionnait déjà avec Access97, voir avant...
Bien connaître la version que l'on utilise est plus productif que d'acheter la "dernière" version que l'on ne maîtrise pas ;-))
Ce ne sont pas des idées ;-) Cela fonctionnait déjà avec Access97, voir avant...
Et même 95. Access 2 je ne suis plus très sûr.
Bien connaître la version que l'on utilise est plus productif que d'acheter la "dernière" version que l'on ne maîtrise pas ;-))
Pour sûr.
Parfois je ne m'embête pas, j'ai l'habitude d'un truc sophistiqué et je fonce. Mais c'est vrai que c'est utile de pouvoir penser à des choses plus simples.
3stone a écrit, le 11/07/2008 00:09 :
Ce ne sont pas des idées ;-)
Cela fonctionnait déjà avec Access97, voir avant...
Et même 95.
Access 2 je ne suis plus très sûr.
Bien connaître la version que l'on utilise est plus productif que
d'acheter la "dernière" version que l'on ne maîtrise pas ;-))
Pour sûr.
Parfois je ne m'embête pas, j'ai l'habitude d'un truc sophistiqué et je
fonce. Mais c'est vrai que c'est utile de pouvoir penser à des choses
plus simples.
Ce ne sont pas des idées ;-) Cela fonctionnait déjà avec Access97, voir avant...
Et même 95. Access 2 je ne suis plus très sûr.
Bien connaître la version que l'on utilise est plus productif que d'acheter la "dernière" version que l'on ne maîtrise pas ;-))
Pour sûr.
Parfois je ne m'embête pas, j'ai l'habitude d'un truc sophistiqué et je fonce. Mais c'est vrai que c'est utile de pouvoir penser à des choses plus simples.
