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 !)
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 !)
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 !)
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ér al de ma
qu'appelles tu "débogage général" ? la compilation du code VBA ?
un corruption....
un problème de références ?
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ér al de ma
qu'appelles tu "débogage général" ? la compilation du code VBA ?
un corruption....
un problème de références ?
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ér al de ma
qu'appelles tu "débogage général" ? la compilation du code VBA ?
un corruption....
un problème de références ?
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...
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'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[
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...
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'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[
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...
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'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[
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
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
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
Cela me fait peur.... tu ne compile pas avant chaque sortie de l' diteur
et avant d'ex cuter le code ?
> 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
Cela me fait peur.... tu ne compile pas avant chaque sortie de l' diteur
et avant d'ex cuter le code ?
> 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
Cela me fait peur.... tu ne compile pas avant chaque sortie de l' diteur
et avant d'ex cuter le code ?
> 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
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
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 ?).
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 ?
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
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 ?).
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 ?
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
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 ?).
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 ?
Certains roulent depuis trente ans, mais toujours aussi mal ;-))
Ce n'est donc pas une (bonne) raison.
Il est donc fortement conseill de compiler le code avant m me
de quiter l' diteur. Plus t t on corrige, mieux c'est.
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!
Certains roulent depuis trente ans, mais toujours aussi mal ;-))
Ce n'est donc pas une (bonne) raison.
Il est donc fortement conseill de compiler le code avant m me
de quiter l' diteur. Plus t t on corrige, mieux c'est.
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!
Certains roulent depuis trente ans, mais toujours aussi mal ;-))
Ce n'est donc pas une (bonne) raison.
Il est donc fortement conseill de compiler le code avant m me
de quiter l' diteur. Plus t t on corrige, mieux c'est.
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 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 ?
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 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 ?
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 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 ?
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
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.
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
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.
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
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.
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
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
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