OVH Cloud OVH Cloud

Méthode introuvable... du jour au lendemain !?

20 réponses
Avatar
gauso
Bonjour,
Ph=E9nom=E8ne incompr=E9hensible (pour moi !) : je g=E8re et d=E9veloppe un=
e
base de donn=E9es partag=E9e en r=E9seau d'une dizaine de postes (avec
fragmentation en 2 bases : donn=E9es/objets...).
Derni=E8rement j'ai d=E9velopp=E9 quelques formulaires =E0 partir d'une cop=
ie
de ma table objets sur mon disque dur (C:) (chose que je ne fais pas
d'habitude... je d=E9veloppe d'ordinaire directement sur le r=E9seau).
Ayant termin=E9 mon d=E9veloppement, je lan=E7e un d=E9bogage g=E9n=E9ral d=
e ma
base, et voil=E0 que le syst=E8me s'arr=EAte sur des bouts du code auquel j=
e
n'ai pas touch=E9 et sur lequel le syst=E8me ne s'=E9tait jamais arr=EAt=E9=
-
comme s'il ne le reconnaissait plus (en l'occurrence ici sur
"oldvalue") -
Chose encore plus =E9trange si je teste la fonction posant soit disant
probl=E8me, celle-ci fonctionne parfaitement (g=E8re parfaitement le
"oldvalue" !) !!?

Quelqu'un aurait une explication =E0 me fournir ?
(J'ai essay=E9 d=E9j=E0 le r=E9-export complet de ma base dans une nouvelle=
...
mais rien =E0 faire !)
Par avance, merci :o)

10 réponses

1 2
Avatar
Gloops
gauso a écrit, le 31/10/2010 03:42 :


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.



Bonjour,

Si il y a un moyen, m'est avis qu'il faut le chercher du côté de
Outils/Analyse.

Si de ce côté on n'a pas toutes les informations requises, je crains
qu'on ne coupe pas à lancer une recherche pour chaque nom de requête, à
travers toute la base.

Ah oui mais attention, on peut demander la recherche dans tous les
modules, mais si on veut voir si une requête est appelée depuis un
contrôle ... si je ne m'abuse il faudra appeler Outils/Documentation,
documenter tout, convertir ensuite le résultat en document Word, et
effectuer ensuite la recherche dans le document Word. Mais pas faire ça
quand on attend un client une demi-heure après.
Avatar
3stone
Salut,

gauso wrote:
[...]
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) ??




Depuis Access 2003, tu dispose des "Dépendances d'objets"
(dans le menu "Affichage")

Raymond avait en son temps fait un petit article sur le sujet:
http://officesystemaccess.seneque.net/spc_2003_depend.htm

Un conseil, méfie toi tout de même... et ne supprime pas
directement un objet, mais renomme le plutôt, en le
préfixant par un double "__" par exemple.
Lorsque après un usage intensif tu n'obtiens pas de message
d'erreur, tu pourras alors supprimer ces objets.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Avatar
3stone
Salut,

Gloops wrote:
[...]
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 ?




OUI, et tu devrais te retenir avant de polluer une conversation !!

Personnellement, je n'ai que faire de tes "tendances", si tu ne sais
expliquer le pourquoi du comment...
Il est d'ailleurs d'usage de dire "je pense que..." lorsque l'on
n'est pas sûr de ce que l'on avance ;-)

Pour ce qui est du "Me" cela ne fait JAMAIS référence à
l'enregistrement courant, ni à un quelconque autre enregistrement!
"Me" designe une instance du formulaire (ou état) courant, celui
dans lequel le code s'exécute !

Me.Client est un champ qui doit faire partie de la source du
formulaire, mais ne doit pas nécessairement être "déposé"
sur ce formulaire.
Me!Client désigne la zone de texte qui :
1. sera forcément déposée sur le formulaire
2. aura probablement (mais non obligatoirement) le champ client
comme source

Pour Rs.Fields("Client bizarre"), c'est la plus mauvaise façon
de l'écrire (mais parfois nécessaire) car c'est la plus lente
à l'exécution :-/

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Avatar
gauso
Bonsoir,

Je connaissais la fonction "Dépendances d'objets" mais n'avait jamais
été jusqu'au bout : cela mettait tellement de temps que j'interrompais
le processus en cours de route, pensant que cela n'aboutirait jamais !
Finalement j'ai relancé cela ce soir en laissant les choses prendre
leur temps : et ça marche en effet !
Je vais donc pouvoir regarder tout ça en détail,

Merci pour tous tes bons conseils Pierre (et merci quand même à
Gloops ;o),
Cordialement,
Sonia.
Avatar
gauso
J'ai parlé trop vite : en fait, j'avais du déjà faire l'opération
jusqu'au bout il y a longtemps, pour constater, ce que je constate à
nouveau : le travail est à moitié fait puisque la procédure ne
recherche ni dans le code, ni dans les sources données des
contrôles !!
Donc, ne sert quasiment à rien !
Je laisses tomber : tant pis, pas de ménage dans ma base !
(Penser à demander à Bill Gates pour Noël d'aller un peu plus loin
dans les outils de gestion qu'il propose à ses clients ? ;o)

Bonne soirée,
Sonia.
Avatar
3stone
Salut,

gauso wrote:
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)
Avatar
gauso
Je pensais la conversation terminée, mais moi si on me relance ;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.
Tu me diras ma méthode ne doit pas être si au point que cela puisque
j'ai aujourd'hui tant de doutes sur certaines requêtes (bien sûr, je
ne parles pas des tables : là quand même je suis sûre que toutes
celles qui existent sont utiles ! même si je pourrais remettre en
question certains champs...), ...
Si j'étais si méthodique, je devrais arriver à faire "le ménage" au
fur et à mesure.... Mais voilà, il y a la théorie et la pratique : le
développement dans l'urgence et la flemme aussi (quand on est arrivé à
obtenir ce qu'on veut, et que l'on en a bavé, le ménage passe
après ;o)
Et puis, pour tout dire, ce n'est même pas tant le fait que les
requêtes soient ou non utilisées qui me posent problème, mais surtout ,
j'ai le soupçon qu'il y en a trop et que certaines doivent faire
double emploi... et là c'est plus compliqué comme boulot (!)

Mais bon, il faudra bien qu'un jour je fasse ce travail d'inventaire
et de pointage systématique, car par définition je ne supportes pas le
désordre (déformation professionnelle donc ;o) : aller, à force d'en
parler, je crois que je vais m'y mettre (j'ai justement quelques jours
devant moi !),
Souhaite moi bon courage ;o),

Amitiés,
Sonia.


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)
Avatar
3stone
Bonsoir,

gauso wrote:
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).



Lorsqu'il y a "une" méthode, c'est déjà bien pas mal!

Le problème, si problème il y a, vient souvent du fait que l'on fait
au fur et à mesure que l'on apprend, ainsi que les bases qui
continuent à être adaptées et étendues.


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.



Le problème ou plutot la difficulté est réelle. On peut faire des
déclarations et jongler avec des variables, à un point tel que même
un humain peut avoir des difficultés à débrouiller les noeuds.
C'est une des raisons pour laquelle je préfère une répétition,
plutôt que de ne plus savoir à quel endroit chercher.
Mais, cela aussi n'a pas toujours été le cas :o)


Souhaite moi bon courage ;o),



S'y prendre par tranche ou section, et à l'occasion, peut aider.

Hé, bon courage !

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Avatar
gauso
Bonjour,

Juste pour te dire - en guise de conclusion - que j'ai testé la
décompilation complète que tu me conseillais et que tout s'est passé
au petit poil : à priori pas de "cottage cheese" dans le code et ma
base à maigri de plus de la moitié de son poids (de 39 Mo, passée à
11 :o),

Donc ça + le grand ménage que je suis en train de faire, ça devrait
lui donner une seconde jeunesse,

Merci pour tout,
Sonia.
Avatar
RideHickul
'lut,

euh ... désolé si je suis complètement hors-sujet, mais un code qui s'arrète
sur un turc qui marche nickel d'habitude, c'est souvent une référence
manquante (Outils -> Reférence)
Peut-être à vérifier avant d'entreprendre le grand "ménage de printemps"
Ok ok on est début novembre : je me tais et je vais me recouché ...

RideHickul


"gauso" a écrit dans le message de news:

Bonjour,
Phénomène incompréhensible (pour moi !) : je gère et développe une
base de données partagée en réseau d'une dizaine de postes (avec
fragmentation en 2 bases : données/objets...).
Dernièrement j'ai développé quelques formulaires à partir d'une copie
de ma table objets sur mon disque dur (C:) (chose que je ne fais pas
d'habitude... je développe d'ordinaire directement sur le réseau).
Ayant terminé mon développement, je lançe un débogage général de ma
base, et voilà que le système s'arrête sur des bouts du code auquel je
n'ai pas touché et sur lequel le système ne s'était jamais arrêté -
comme s'il ne le reconnaissait plus (en l'occurrence ici sur
"oldvalue") -
Chose encore plus étrange si je teste la fonction posant soit disant
problème, celle-ci fonctionne parfaitement (gère parfaitement le
"oldvalue" !) !!?

Quelqu'un aurait une explication à me fournir ?
(J'ai essayé déjà le ré-export complet de ma base dans une nouvelle...
mais rien à faire !)
Par avance, merci :o)
1 2