Ce ne sont pas les champs qu'il faut modifier, mais le nom des zones
de texte...
... j'avais bien compris : mais ça fait du monde quand même...pour autant qu'ils interviennent dans le code VBA.
... un peu moins, donc ;o)Une autre m thode (souvent n cessaire) est d'utiliser le "!"
point d'exclamation pour sp cifier que tu t'adresse la
zone de texte...
Me.Client est le champ
Me!Client est la zone de texte
Alors ça c'est une bonne nouvelle car j'utilise la plupart du temps
les !La "d compilation" la fonction suivante:
tout le code compil est jet par dessus bord, pour ne garder que
le code canonique (celui que tu cris)
Ensuite, il faut compiler et compacter la base pour voir ce qu'il en e st.
Si la base a fortement diminu de taille, il y avait un probl me...
Souvent, mais pas n cessairement, la d compilation fait donc fondre
la taille de la base... malgr que tu l'aies toujours compact tr s
consciensieusement...
Cela indique que la base trainait du code "mort", c. d. du code
incorrectement compil et qu'Access est incapable d' l miner par
la m thode conventionnelle. Par contre, ce code mort peut induire
un mauvais fonctionnement.
Bon, faudra que je teste alors... (même si ensuite tester toutes les
fonctions, cela risque aussi de prendre du temps !)
Connaîtrais tu par hasard une méthode pour détecter les requête s qui
ne sont utilisées ni dans du code ni dans les formulaires (en source
de données de formulaire ou de champs) : j'ai un paquet de requêtes et
je soupçonne que certaines pourraient être supprimées (mais là aussi
cela me prendrait beaucoup de temps de devoir les vérifier
manuellement une à une) ??
Tu vas finir par penser que je suis une feignante : pas le cas, crois-
moi ;o)
Cordialement,
Sonia.
Ce ne sont pas les champs qu'il faut modifier, mais le nom des zones
de texte...
... j'avais bien compris : mais ça fait du monde quand même...
pour autant qu'ils interviennent dans le code VBA.
... un peu moins, donc ;o)
Une autre m thode (souvent n cessaire) est d'utiliser le "!"
point d'exclamation pour sp cifier que tu t'adresse la
zone de texte...
Me.Client est le champ
Me!Client est la zone de texte
Alors ça c'est une bonne nouvelle car j'utilise la plupart du temps
les !
La "d compilation" la fonction suivante:
tout le code compil est jet par dessus bord, pour ne garder que
le code canonique (celui que tu cris)
Ensuite, il faut compiler et compacter la base pour voir ce qu'il en e st.
Si la base a fortement diminu de taille, il y avait un probl me...
Souvent, mais pas n cessairement, la d compilation fait donc fondre
la taille de la base... malgr que tu l'aies toujours compact tr s
consciensieusement...
Cela indique que la base trainait du code "mort", c. d. du code
incorrectement compil et qu'Access est incapable d' l miner par
la m thode conventionnelle. Par contre, ce code mort peut induire
un mauvais fonctionnement.
Bon, faudra que je teste alors... (même si ensuite tester toutes les
fonctions, cela risque aussi de prendre du temps !)
Connaîtrais tu par hasard une méthode pour détecter les requête s qui
ne sont utilisées ni dans du code ni dans les formulaires (en source
de données de formulaire ou de champs) : j'ai un paquet de requêtes et
je soupçonne que certaines pourraient être supprimées (mais là aussi
cela me prendrait beaucoup de temps de devoir les vérifier
manuellement une à une) ??
Tu vas finir par penser que je suis une feignante : pas le cas, crois-
moi ;o)
Cordialement,
Sonia.
Ce ne sont pas les champs qu'il faut modifier, mais le nom des zones
de texte...
... j'avais bien compris : mais ça fait du monde quand même...pour autant qu'ils interviennent dans le code VBA.
... un peu moins, donc ;o)Une autre m thode (souvent n cessaire) est d'utiliser le "!"
point d'exclamation pour sp cifier que tu t'adresse la
zone de texte...
Me.Client est le champ
Me!Client est la zone de texte
Alors ça c'est une bonne nouvelle car j'utilise la plupart du temps
les !La "d compilation" la fonction suivante:
tout le code compil est jet par dessus bord, pour ne garder que
le code canonique (celui que tu cris)
Ensuite, il faut compiler et compacter la base pour voir ce qu'il en e st.
Si la base a fortement diminu de taille, il y avait un probl me...
Souvent, mais pas n cessairement, la d compilation fait donc fondre
la taille de la base... malgr que tu l'aies toujours compact tr s
consciensieusement...
Cela indique que la base trainait du code "mort", c. d. du code
incorrectement compil et qu'Access est incapable d' l miner par
la m thode conventionnelle. Par contre, ce code mort peut induire
un mauvais fonctionnement.
Bon, faudra que je teste alors... (même si ensuite tester toutes les
fonctions, cela risque aussi de prendre du temps !)
Connaîtrais tu par hasard une méthode pour détecter les requête s qui
ne sont utilisées ni dans du code ni dans les formulaires (en source
de données de formulaire ou de champs) : j'ai un paquet de requêtes et
je soupçonne que certaines pourraient être supprimées (mais là aussi
cela me prendrait beaucoup de temps de devoir les vérifier
manuellement une à une) ??
Tu vas finir par penser que je suis une feignante : pas le cas, crois-
moi ;o)
Cordialement,
Sonia.
Connaîtrais tu par hasard une méthode pour détecter les requêtes qui
ne sont utilisées ni dans du code ni dans les formulaires (en source
de données de formulaire ou de champs) : j'ai un paquet de requêtes et
je soupçonne que certaines pourraient être supprimées (mais là aussi
cela me prendrait beaucoup de temps de devoir les vérifier
manuellement une à une) ??
Connaîtrais tu par hasard une méthode pour détecter les requêtes qui
ne sont utilisées ni dans du code ni dans les formulaires (en source
de données de formulaire ou de champs) : j'ai un paquet de requêtes et
je soupçonne que certaines pourraient être supprimées (mais là aussi
cela me prendrait beaucoup de temps de devoir les vérifier
manuellement une à une) ??
Connaîtrais tu par hasard une méthode pour détecter les requêtes qui
ne sont utilisées ni dans du code ni dans les formulaires (en source
de données de formulaire ou de champs) : j'ai un paquet de requêtes et
je soupçonne que certaines pourraient être supprimées (mais là aussi
cela me prendrait beaucoup de temps de devoir les vérifier
manuellement une à une) ??
Je ne sais pas si c'est parce que nous sommes Dimanche, mais j'ai
tendance à séparer le nom d'un formulaire du nom d'un contrôle par un
point. Par ailleurs je sépare le nom d'un jeu d'enregistrements de
celui d'un champ par un point d'exclamation, ce qui m'encouragerait à
voir Me!Client comme référent Me à l'enregistrement courant, plutôt
qu'au formulaire proprement dit comme contenant des contrôles.
Bien entendu le point d'exclamation de Rs!Client ne s'utilise que pour
autant que le nom de champ ne comporte pas d'espace, sinon c'est
Rs.Fields("Client bizarre")
à moins peut-être de mettre des crochets autour du nom
mais de toute façon c'est mieux de ne pas mettre d'espace dans un nom
de champ.
Est-ce que je me rétame sur toute la ligne ?
Je ne sais pas si c'est parce que nous sommes Dimanche, mais j'ai
tendance à séparer le nom d'un formulaire du nom d'un contrôle par un
point. Par ailleurs je sépare le nom d'un jeu d'enregistrements de
celui d'un champ par un point d'exclamation, ce qui m'encouragerait à
voir Me!Client comme référent Me à l'enregistrement courant, plutôt
qu'au formulaire proprement dit comme contenant des contrôles.
Bien entendu le point d'exclamation de Rs!Client ne s'utilise que pour
autant que le nom de champ ne comporte pas d'espace, sinon c'est
Rs.Fields("Client bizarre")
à moins peut-être de mettre des crochets autour du nom
mais de toute façon c'est mieux de ne pas mettre d'espace dans un nom
de champ.
Est-ce que je me rétame sur toute la ligne ?
Je ne sais pas si c'est parce que nous sommes Dimanche, mais j'ai
tendance à séparer le nom d'un formulaire du nom d'un contrôle par un
point. Par ailleurs je sépare le nom d'un jeu d'enregistrements de
celui d'un champ par un point d'exclamation, ce qui m'encouragerait à
voir Me!Client comme référent Me à l'enregistrement courant, plutôt
qu'au formulaire proprement dit comme contenant des contrôles.
Bien entendu le point d'exclamation de Rs!Client ne s'utilise que pour
autant que le nom de champ ne comporte pas d'espace, sinon c'est
Rs.Fields("Client bizarre")
à moins peut-être de mettre des crochets autour du nom
mais de toute façon c'est mieux de ne pas mettre d'espace dans un nom
de champ.
Est-ce que je me rétame sur toute la ligne ?
le travail est à moitié fait puisque la procédure ne
recherche ni dans le code, ni dans les sources données des
contrôles !!
le travail est à moitié fait puisque la procédure ne
recherche ni dans le code, ni dans les sources données des
contrôles !!
le travail est à moitié fait puisque la procédure ne
recherche ni dans le code, ni dans les sources données des
contrôles !!
C'est normal ;-)
Une requête enregistrée est... un objet !
Une phrase SQL, comme on les crée dans dans le VBA,
éventuelement coupé en multiple morceaux, n'est pas
un objet et ne peut être détecté comme dépendance.
Il faudrait une analyse de texte (et ultra performante)
pour arriver à obtenir cela.
Tout au plus, peux tu rechercher le nom des tables
dans le code, et encore, si on utilise des alias...
En fait, la "bonne" méthode est justement... d'en avoir,
de la méthode.
Lorsque l'on fait des tests, tout azimut, il vaut mieux faire
cela dans une copie de la base de travail. Lorsque l'on obtient
le résultat souhaité, on importe uniquement ces objets
dans la base de travail, les essais restent là et peuvent
être supprimés.
Tout cela vient, bien sûr, avec le temps et l'habitude... Car, ne
dit on pas que cet en forgeant que l'on devient forgeron ? ;-)
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
C'est normal ;-)
Une requête enregistrée est... un objet !
Une phrase SQL, comme on les crée dans dans le VBA,
éventuelement coupé en multiple morceaux, n'est pas
un objet et ne peut être détecté comme dépendance.
Il faudrait une analyse de texte (et ultra performante)
pour arriver à obtenir cela.
Tout au plus, peux tu rechercher le nom des tables
dans le code, et encore, si on utilise des alias...
En fait, la "bonne" méthode est justement... d'en avoir,
de la méthode.
Lorsque l'on fait des tests, tout azimut, il vaut mieux faire
cela dans une copie de la base de travail. Lorsque l'on obtient
le résultat souhaité, on importe uniquement ces objets
dans la base de travail, les essais restent là et peuvent
être supprimés.
Tout cela vient, bien sûr, avec le temps et l'habitude... Car, ne
dit on pas que cet en forgeant que l'on devient forgeron ? ;-)
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
C'est normal ;-)
Une requête enregistrée est... un objet !
Une phrase SQL, comme on les crée dans dans le VBA,
éventuelement coupé en multiple morceaux, n'est pas
un objet et ne peut être détecté comme dépendance.
Il faudrait une analyse de texte (et ultra performante)
pour arriver à obtenir cela.
Tout au plus, peux tu rechercher le nom des tables
dans le code, et encore, si on utilise des alias...
En fait, la "bonne" méthode est justement... d'en avoir,
de la méthode.
Lorsque l'on fait des tests, tout azimut, il vaut mieux faire
cela dans une copie de la base de travail. Lorsque l'on obtient
le résultat souhaité, on importe uniquement ces objets
dans la base de travail, les essais restent là et peuvent
être supprimés.
Tout cela vient, bien sûr, avec le temps et l'habitude... Car, ne
dit on pas que cet en forgeant que l'on devient forgeron ? ;-)
--
A+
Pierre (3stone) Access MVP
Perso:http://www.3stone.be/
MPFA:http://www.mpfa.info/ (infos générales)
Normalement j'en ai : de la méthode... c'est même mon boulot en
quelque sorte (mais je ne vais pas raconter ma vie ici ;o).
J'entends bien que la recherche dans le code en tous les cas (je ne
sais si cela pourrait se faire ainsi dans les sql non enregistrées..),
devrait se faire en "plein texte", mais justement (et j'imagine que je
ne suis pas la seule) je me suis donné une méthode de dénomination de
mes objets (tables, requêtes, etc.) qui fait qu'il ne pourrait y avoir
aucune confusion possible.
Souhaite moi bon courage ;o),
Normalement j'en ai : de la méthode... c'est même mon boulot en
quelque sorte (mais je ne vais pas raconter ma vie ici ;o).
J'entends bien que la recherche dans le code en tous les cas (je ne
sais si cela pourrait se faire ainsi dans les sql non enregistrées..),
devrait se faire en "plein texte", mais justement (et j'imagine que je
ne suis pas la seule) je me suis donné une méthode de dénomination de
mes objets (tables, requêtes, etc.) qui fait qu'il ne pourrait y avoir
aucune confusion possible.
Souhaite moi bon courage ;o),
Normalement j'en ai : de la méthode... c'est même mon boulot en
quelque sorte (mais je ne vais pas raconter ma vie ici ;o).
J'entends bien que la recherche dans le code en tous les cas (je ne
sais si cela pourrait se faire ainsi dans les sql non enregistrées..),
devrait se faire en "plein texte", mais justement (et j'imagine que je
ne suis pas la seule) je me suis donné une méthode de dénomination de
mes objets (tables, requêtes, etc.) qui fait qu'il ne pourrait y avoir
aucune confusion possible.
Souhaite moi bon courage ;o),