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

Le
gauso
Bonjour,
Phénomène incompréhensible (pour moi !) : je gère et développe un=
e
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 cop=
ie
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 d=
e ma
base, et voilà que le système s'arrête sur des bouts du code auquel j=
e
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)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
3stone
Le #22729731
Salut,

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




Heu... tu ne dit pas avec quelle version d'Access, car les dernières
version empêche de modifier l'application lorsque la base "tourne".



Ayant terminé mon développement, je lançe un débogage général de ma




qu'appelles tu "débogage général" ? la compilation du code VBA ?


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") -



un corruption....

Chose encore plus étrange si je teste la fonction posant soit disant
problème, celle-ci fonctionne parfaitement (gère parfaitement le
"oldvalue" !) !!?




un problème de références ?


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 !)




--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
gauso
Le #22730141
Bonjour monsieur Pierre et merci pour votre réponse :o)


Heu... tu ne dit pas avec quelle version d'Access, car les dernières
version empêche de modifier l'application lorsque la base "tourne".




Je suis toujours avec la version 2003 (au fait faut-il passer à une
autre version ? utile ?)

> Ayant terminé mon développement, je lançe un débogage génér al de ma
qu'appelles tu "débogage général" ?   la compilation du code VBA ?



Oui, c'est effectivement de cela que je parles...

un corruption....



Ben, si c'était une corruption le fait d'avoir tout exporté dans une
nouvelle base aurait réglé le problème non ?


un problème de références ?



Et je n'ai évidemment pas touché aux références (vérifié qu'ell es
étaient bien identiques avant...). Le même bibliothèque de référe nce
donc, et le même code...
Je n'ai pas non plus fait de "miracles" au cours du développement que
j'ai réalisé ces derniers jours : essentiellement ajouté du code dans
2 ou 3 formulaires, pour passer de filtres à filtres (beaucoup de
"RecordsetClone.FindFirst") et de la gestion de sous-formulaires...

Que faire ? je n'aime pas laisser ma base dans cet état :o[
3stone
Le #22734071
Salut,

gauso wrote:
Ayant terminé mon développement, je lançe un débogage général de ma


qu'appelles tu "débogage général" ? la compilation du code VBA ?



Oui, c'est effectivement de cela que je parles...




Cela me fait peur.... tu ne compile pas avant chaque sortie de l'éditeur
et avant d'exécuter le code ?





un corruption....



Ben, si c'était une corruption le fait d'avoir tout exporté dans une
nouvelle base aurait réglé le problème non ?




Oh non... certaine corruption peuvent être limité à un formulaire,
une fonction, etc.

Le fait est que, souvent, l'import de la base dans un base vierge,
permet de mettre le doigt sur le problème, mais ce n'est pas certain.



un problème de références ?



Et je n'ai évidemment pas touché aux références (vérifié qu'elles
étaient bien identiques avant...). Le même bibliothèque de référence
donc, et le même code...
Je n'ai pas non plus fait de "miracles" au cours du développement que
j'ai réalisé ces derniers jours : essentiellement ajouté du code dans
2 ou 3 formulaires, pour passer de filtres à filtres (beaucoup de
"RecordsetClone.FindFirst") et de la gestion de sous-formulaires...

Que faire ? je n'aime pas laisser ma base dans cet état :o[



Effectivement, lorsque l'on "sent" qu'il y a un problème, il vaut mieux
faire une copie de la base (que l'on peut utiliser avec prudence et
sous surveillance) et ne pas continuer le massacre sur la version "originale".

Tu peux faire un grand nettoyage par une décompilation du code VBA.
Je te conseille de lire attentivement cet article et de faire le test
sur une *copie* !
http://www.trigeminal.com/usenet/usenet004.asp?1036

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
blaise cacramp
Le #22734371
"3stone" iael3l$6e0$

Tu peux faire un grand nettoyage par une décompilation du code VBA.
Je te conseille de lire attentivement cet article et de faire le test
sur une *copie* !
http://www.trigeminal.com/usenet/usenet004.asp?1036




+1
gauso
Le #22736571
Bonjour,..

Cela me fait peur.... tu ne compile pas avant chaque sortie de l' diteur
et avant d'ex cuter le code ?



Euh !? je ne compile pas à chaque fois que je modifie un bout de code
c'est vrai (et du coup il m'arrive assez souvent d'avoir des bogues...
mais ça fait 10 ans que je pratique ainsi, sans que cela ait causé de
dégâts : enfin en apparence !?)


> Ben, si c' tait une corruption le fait d'avoir tout export dans une
> nouvelle base aurait r gl le probl me non ?
Oh non... certaine corruption peuvent tre limit un formulaire, une foncti on, etc.
Le fait est que, souvent, l'import de la base dans un base vierge,
permet de mettre le doigt sur le probl me, mais ce n'est pas certain.



Effectivement, lorsque l'on "sent" qu'il y a un probl me, il vaut mieux
faire une copie de la base (que l'on peut utiliser avec prudence et
sous surveillance) et ne pas continuer le massacre sur la version "origin ale".
Tu peux faire un grand nettoyage par une d compilation du code VBA.
Je te conseille de lire attentivement cet article et de faire le test
sur une *copie* !http://www.trigeminal.com/usenet/usenet004.asp?1036



Je ne me suis pas lancé là dedans : fait trop peur ! (le dois-je quand
même ?).

Par contre j'ai recompilé et supprimé le code à chaque fois que le
système bloquait : ce qui ne s'est produit que 3 fois sur le MEME sous
formulaire (sur lequel j'ai effectivement travaillé ces derniers
jours) : 2 fois sur Oldvalue, 1 fois sur SetFocus. Maintenant tout va
bien : il semble bien que le problème vienne de ce sous-formulaire...
Je supposes que tu vas me conseiller de le supprimer et d'en refaire
un nouveau ?
Puis-je m'en sortir comme cela ?

Merci encore pour ton aide,
Sonia.
3stone
Le #22737351
Salut,

gauso wrote:
Cela me fait peur.... tu ne compile pas avant chaque sortie de l'
diteur
et avant d'ex cuter le code ?



Euh !? je ne compile pas à chaque fois que je modifie un bout de code
c'est vrai (et du coup il m'arrive assez souvent d'avoir des bogues...
mais ça fait 10 ans que je pratique ainsi, sans que cela ait causé de
dégâts : enfin en apparence !?)




Certains roulent depuis trente ans, mais toujours aussi mal ;-))
Ce n'est donc pas une (bonne) raison.

Soyont clair! Le code est toujours compilé avant d'être exécuté,
Lorsque tu ouvres un formulaire qui contient du code non compilé,
Access compile d'abord ce code, puis seulement l'exécute...
à condition que tout va bien.
Mais voilà, lorsque cela ne "vas pas", les autres éléments viennent
s'ajouter au problème et peuvent justement produire des corruptions
de formulaire, de code (qui produit du code "mort"), etc.

Il est donc fortement conseillé de compiler le code avant même
de quiter l'éditeur. Plus tôt on corrige, mieux c'est.




Ben, si c' tait une corruption le fait d'avoir tout export dans une
nouvelle base aurait r gl le probl me non ?


Oh non... certaine corruption peuvent tre limit un formulaire, une
fonction, etc. Le fait est que, souvent, l'import de la base dans un
base vierge,
permet de mettre le doigt sur le probl me, mais ce n'est pas certain.





Effectivement, lorsque l'on "sent" qu'il y a un probl me, il vaut
mieux
faire une copie de la base (que l'on peut utiliser avec prudence et
sous surveillance) et ne pas continuer le massacre sur la version
"originale". Tu peux faire un grand nettoyage par une d compilation
du code VBA.
Je te conseille de lire attentivement cet article et de faire le test
sur une *copie* !http://www.trigeminal.com/usenet/usenet004.asp?1036



Je ne me suis pas lancé là dedans : fait trop peur ! (le dois-je quand
même ?).




Si tu le fais sur une copie, il n'y a pas de risque... mais => voir plus loin


Par contre j'ai recompilé et supprimé le code à chaque fois que le
système bloquait : ce qui ne s'est produit que 3 fois sur le MEME sous
formulaire (sur lequel j'ai effectivement travaillé ces derniers
jours) : 2 fois sur Oldvalue, 1 fois sur SetFocus.




Attention !...

.OldValue est un propriété d'une zone de texte et non d'un champ !!!

Je reproche depuis toujours à Access d'utiliser par défaut, le même
nom pour la zone de texte que le champ source ! Il devrait le
préfixer par un simple "txt" par exemple.

En fait, celui qui code en VBA se doit de modifier la propriété "Nom"
de la zone de texte. Voir Propriétés, onglet Autres, ligne Nom
Par défaut, Access utilise le nom du champ et cela peu occasioner
des problèmes d'adressage.

Me.Client.Value => on parle du champ
Me.txtClient.OldValue => on parle de la zone de texte, sans équivoque!


Maintenant tout va
bien : il semble bien que le problème vienne de ce sous-formulaire...
Je supposes que tu vas me conseiller de le supprimer et d'en refaire
un nouveau ?
Puis-je m'en sortir comme cela ?



Vérifie le point précédant...

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

Certains roulent depuis trente ans, mais toujours aussi mal ;-))
Ce n'est donc pas une (bonne) raison.



M'étonnerait pas que je "roule" assez mal : jamais passé le "code"...
de la route ;o)
Mais le nez sur le guidon : je rêve d'avoir le temps d'acquérir une
vraie formation et faire un grand "ménage" dans cette base construite
au fur et à mesure et sans doute pas toujours de façon très orthodoxe ,
mais comment trouver le temps !?


Il est donc fortement conseill de compiler le code avant m me
de quiter l' diteur. Plus t t on corrige, mieux c'est.



C'est promis, je le ferais désormais systématiquement !



Attention !...
.OldValue est un propri t d'une zone de texte et non d'un champ !!!

Je reproche depuis toujours Access d'utiliser par d faut, le m me
nom pour la zone de texte que le champ source ! Il devrait le
pr fixer par un simple "txt" par exemple.
En fait, celui qui code en VBA se doit de modifier la propri t "Nom"
de la zone de texte. Voir Propri t s, onglet Autres, ligne Nom
Par d faut, Access utilise le nom du champ et cela peu occasioner
des probl mes d'adressage.

Me.Client.Value   => on parle du champ
Me.txtClient.OldValue => on parle de la zone de texte, sans quivoque!



Hmm ! Bon à savoir, mais si je dois renommer tous les champs de ma
base dans les formulaires, je ne suis pas sortie de l'auberge (c'est
une grosse base : quelques 120 tables, 150 formulaires.... sans
compter les requêtes, les états...)
Je n'ai jamais rencontré de problème d'adressage à priori...

Par contre, j'ai réalisé après coup - concernant le sous-formulaire e n
question, que le système buggait en fait sur du code qui n'était plus
actif (champs et bouton supprimés) : cela ne fait peut-être pas
avancer le schmilblick, mais une précision à tout hasard...

Est-ce que le fait de faire la "grande décompilation" dont tu parles
pourrait repérer des problèmes qui ne seraient pas aujourd'hui
identifié par la compilation normale ?

Merci encore,
Sonia.
3stone
Le #22739471
Salut,

gauso wrote:
[...]
Hmm ! Bon à savoir, mais si je dois renommer tous les champs de ma
base dans les formulaires, je ne suis pas sortie de l'auberge (c'est
une grosse base : quelques 120 tables, 150 formulaires.... sans
compter les requêtes, les états...)



Ce ne sont pas les champs qu'il faut modifier, mais le nom des zones
de texte... pour autant qu'ils interviennent dans le code VBA.
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


Je n'ai jamais rencontré de problème d'adressage à priori...



Lorsque l'on dit: ca ne marche pas... cela peut être la cause.


Par contre, j'ai réalisé après coup - concernant le sous-formulaire en
question, que le système buggait en fait sur du code qui n'était plus
actif (champs et bouton supprimés) : cela ne fait peut-être pas
avancer le schmilblick, mais une précision à tout hasard...

Est-ce que le fait de faire la "grande décompilation" dont tu parles
pourrait repérer des problèmes qui ne seraient pas aujourd'hui
identifié par la compilation normale ?



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 est.
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.

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

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 est.
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êtes qu i
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à auss i
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.
Gloops
Le #22741531
Bonjour,

3stone a écrit, le 30/10/2010 22:34 :
Salut,

gauso wrote:
[...]
Hmm ! Bon à savoir, mais si je dois renommer tous les champs de ma
base dans les formulaires, je ne suis pas sortie de l'auberge (c'est
une grosse base : quelques 120 tables, 150 formulaires.... sans
compter les requêtes, les états...)



Ce ne sont pas les champs qu'il faut modifier, mais le nom des zones
de texte... pour autant qu'ils interviennent dans le code VBA.
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




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 celu i
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 d e
champ.

Est-ce que je me rétame sur toute la ligne ?
Publicité
Poster une réponse
Anonyme