Version imprimable
Bonjour à tous,
Existe-t-il un moyen d'obtenir, pour une application Access 2003, la liste des fonctions avec la référence dans laquelle Access va "taper" compte tenu de l'ordre des références paramétré ?
Donc, si une même fonction est présente dans deux références, c'est celle prise par l'application qui m'intéresse (la première, je suppose).
Merci d'avance de votre aide,
Richard.
Bonjour,
Je n'ai pas de réponse à proprement parler mais de manière générale et pour éviter de (se) poser ce genre de question, il faut qualifier chaque objet déclaré, soit par exemple :
Cas de figure où le projet exploite les 2 références DAO et ADO.Code:
2
Si si c'est possibleuh !!!
Il en est de même pour les modules de type Bas :
Mais effectivement, c'est la première qui sera prise en compte de par l'ordre de priorité défini.Code:
2
Argy
Bonjour argyronet,
Merci de ta réponse.
Je comprends ta préconisation de qualifier les objets, mais nous ne maîtrisons pas toujours de A à Z...
Quoiqu'il en soit, il me paraît intéressant de savoir, lors de l'utilisation d'une fonction, dans quelle référence Access va "taper". Cette information n'existe peut-être pas en temps réel lors de l'exécution du programme, mais elle est, forcément, quelque part. En effet, quand la référence manque, la fonction ne marche pas : Access va donc bien "taper" quelque part dans la liste des références (et dans l'ordre indiqué) et se plante s'il ne la trouve pas. Il devrait donc être possible de savoir de quelle bibliothèque provient telle ou telle fonction. Ce serait utile en cas de fonction en doublon.
Peut-être est-il possible, pour une application Access particulière, d'obtenir une liste des références avec, en regard, les fonctions qu'elles proposent. Charge serait à nous, ensuite, et en fonction de l'ordre des références, de savoir où Access va "taper".
Merci de ton aide,
Richard.
Je ne comprends pas pourquoi tu as besoin d'en arriver là...
Un bon dev ne doit pas solliciter une fonction inaccessible.
Quoi qu'il en soit, sur l'objet concerné, la pression sur Shift+F2 te donneras quelques indications mais en aucun cas ce que choisi Access pour prioriser...
Une fonction publique, exceptée en .Net ne peut être surchargée sauf si tu la précèdes de son module père.
Quelle est la raison de ta demande, rencontres-tu des problèmes précis ?
Argy
Bonjour Argy,
Merci de ton intérêt concernant la panade dans laquelle je me trouve...
Ce post est lié à celui-ci :
http://www.developpez.net/forums/d91...e-pdf-creator/
et permet d'aborder le problème de façon plus générale.
Je résume, compte tenu des derniers tests et informations. Je précise que je distribue un .mde sur des PC clients sans Access. Le .mdb source est en Access 2003.
Symptôme :
Sur certains PC clients, certaines requêtes de notre .mde ne fonctionnent pas.
Diagnostic :
Sur ces PC clients, des fonctions présentes dans ces requêtes ne sont pas reconnues alors que sur d'autres PC clients ces requêtes ne posent pas de problème.
Résolution provisoire :
Pour établir cette résolution provisoire, j'ai dû installer Access les PC clients posant problème.
Sur ces PC clients, il suffit de décocher une référence (n'importe laquelle) et de la recocher juste après pour que ce problème soit résolu.
Autant dire que cette résolution n'est pas envisageable car il faut, non seulement laisser Access sur ces PC mais, en plus, modifier le .mdb pour le décochage/cochage d'une référence... En effet, il est impossible d'effectuer cette manipulation sur un .mde.
De même, le code VBA effectuant ce décochage/cochage ne fonctionne pas dans un .mde.
J'ai essayé avec le runtime 2003 et 2007 : problème non résolu.
J'ai désinstallé et ré-installé Office 2003 : problème non résolu.
J'ai essayé avec le runtime 2003 et 2007 et le nouvel Office 2003 : problème non résolu.
Merci d'avance de ton aide,
Richard.
Humm, cas rare mais possible.
Mais tu t'égares dans la piste que tu cibles selon moi.
J'ai déjà rencontré ce cas à cause d'un module de classe avec une erreur dans une enumération ; cette dernière étant instanciée just in time, le compilateur n'a pas su en temps et en heure déceler l'omission...
Donc dans ce cas, il faut modifier l'option d'interprétation des erreurs pour pouvoir tenter de la reproduire...
:arrow: N'as tu pas dans ton projet, une fonction perso nommée Date() ou bien pire encore un champ de table nommé ainsi ?
En fait, si sur certains postes cela ne fonctionne pas, c'est qu'il manque quelque chose ou que s'il ne manque pas, un problème de version ou d'inscription dans le Registre peut être une piste à renifler.
La première question que je me pose est de te demander si tu as mis en place un package d'installation digne de ce nom plutôt que de copier le MDE sur chaque poste ?
Si oui, alors c'est un peu embettant...
Si non, eh bien tu as du travail... ;)
Argy
Re-bonjour,
Non, aucun champ nommé "Date". Mais, comme je l'ai dit, je me suis, effectivement, polarisé sur Date() et la référence PDF Creator alors que d'autres fonctions n'étaient pas, non plus, reconnues (je ne l'ai remarqué qu'après).Citation:
N'as tu pas dans ton projet, une fonction perso nommée Date() ou bien pire encore un champ de table nommé ainsi ?
Désolé, je n'ai pas compris, n'étant pas un spécialiste VBA.Citation:
J'ai déjà rencontré ce cas à cause d'un module de classe avec une erreur dans une enumération ; cette dernière étant instanciée just in time, le compilateur n'a pas su en temps et en heure déceler l'omission...
Donc dans ce cas, il faut modifier l'option d'interprétation des erreurs pour pouvoir tenter de la reproduire...
Tu parles d'interprétation des erreurs dans le code VBA ou autre part ?
Car ces fonctions non reconnues (sans décochage/recochage) sont présentes dans des requêtes. Par exemple, les fonctions :
- Date() ;
- VraiFaux() qui est indiqué "IIf" avant décochage/recochage et reprend la valeur "VraiFaux" après décochage/recochage ;
- etc...
Non, il n'y a pas de package d'installation. Un .bat copie la dernière version du .mde lors du login des clients (NETLOGON).Citation:
La première question que je me pose est de te demander si tu as mis en place un package d'installation digne de ce nom plutôt que de copier le MDE sur chaque poste ?
D'autre part, il me semble avoir lu que le package d'installation n'existe pas, de base, dans Access 2003.
Cette piste me paraît intéressante car le fait de décocher/recocher remet, sans doute, quelque chose en place quelque part. Par contre, je ne sais pas où chercher et, donc, comment tester.Citation:
En fait, si sur certains postes cela ne fonctionne pas, c'est qu'il manque quelque chose ou que s'il ne manque pas, un problème de version ou d'inscription dans le Registre peut être une piste à renifler.
Merci de ton aide,
Richard.
Cela renifle un problème de langue US/FR du poste en question !Citation:
Envoyé par Richard_35
Dans ce cas, il est préférable de ne pas user de requêtes via le QBE mais de tout créér en VBA-SQL ce qui impose l'anglais pour tout quel que soit le langage du poste de travail...
Si en option bien entendu. J'en raconte toute l'histoire dans le lien du précédent post.Citation:
Envoyé par Richard_35
Argy
Bonjour Argy,
Nous ne maîtrisons pas toujours tout dans une application à maintenir, ce serait trop facile... L'application existante contient beaucoup de requêtes créées par l'assisant, donc pas en VBA : convertir toutes les requêtes devient un autre projet...
Compte tenu des éléments suivants :
Symptômes : En modification d'une requête existante, les fonctions "VraiFaux" et "NumChaîne" (par exemple) apparaissent en "IIf" et "Str" et ne sont pas reconnues par Access.
Résolution : Il suffit de décocher une référence (n'importe quelle référence) puis de la recocher pur que Access reconnaisse, de nouveau, "VraiFaux" et "NumChaîne" (par exemple).
Comme je distribue un .mde par copie via le netlogon, le .mde ne peut pas contenir un décochage/recochage forcé dans le code.
Existe-t-il une solution simple (à part l'empaquetage) ?
Merci de ton aide,
Richard.
Bien disons qu'il eût été judicieux pour ne pas dire préférable (woooah, ça faisait longtemps que j'avais pas employé de subjonctif plus-que-parfait...) que ce MDE eût été intallé au moins une fois proprement...
Ensuite, effectivement, procéder par batch est très pratique et rapide.
Donc sur les postes en question, il manque quelque chose qu'il faut que tu installes...
Argy
Ce .mde a déjà fonctionné correctement, sur ces postes. Je ne sais pas quel a été l'élément déclencheur de ce dysfonctionnement.
J'ai déjà désinstallé et réinstallé tout Office.
As-tu une idée sur le "quelque chose" qu'il faudrait réinstaller (sans ré-installer Windows, si possible) ?
Merci de ton aide,
Richard.
:koi: Réinstaller Windows...?
Non, non... tout de même.
Quelles références sont affectées au projet ?
Argy
Voici la liste des références.
Mais, comme je te l'ai dit, le fait de décocher et de recocher n'importe quelle référence résoud le problème.
Merci de ton aide,
Richard.
8O
Ouh, là, là. Elle me semble longue cette liste de référence...!
As-tu vraiment besoin de tout ça ???
J'en connais pas certaines, c'est pour dire !
NodeMgr, ctv OLE... je vois pas les autres
En plus tu utilses conjointement et prioritairement ADO et DAO ; est-ce vraiment justifié.
Comment as-tu fais pour inscrire tous ces composants dans le Regsitre de chaque poste de travail ?
Oui, je me doute que ce simple décochage puisse ête frustrant.
Argy
Je n'en sais rien... j'hérite de cette application.Citation:
As-tu vraiment besoin de tout ça ???
En plus tu utilses conjointement et prioritairement ADO et DAO ; est-ce vraiment justifié.
Comment as-tu fais pour inscrire tous ces composants dans le Regsitre de chaque poste de travail ?
D'où ma question initiale, qui pourrait permettre, entre autre, d'éliminer des références qui ne servent pas. Sinon, nous sommes obligés de décocher une références, de tester TOUTE l'application, de recocher la référence s'il y a plantage, et ainsi de suite...
Si le .mde permettait de d'effectuer un décochage/recochage par VBA, cela m'arrangerait bien...
Si tu as une idée... merci de ton aide,
Richard.
Décoche une réf et compile.
Si ça passe c'est que la réf n'est pas nécessaire.
Décoches les toutes en fait, sauf DAO et encore, non toutes...Citation:
Envoyé par Kloun
Tu verras bien, tant que ça compile pas, c'est qu'il en manque une.
Tu verras alors la ligne en erreur, par exemple :
nécessite une référence à Outlook, alors queCode:
2
n'en necessite pas ou alors, elle est superflue et le développeur précédent a, soit oublié de la décocher, soit ne savait pas développer à ce niveau.Code:
2
C'est pas bien grave, on va finir par trouver...Citation:
Envoyé par Richard
Argy
Bonjour Argy et Kloun,
Effectivement, j'ai résolu le problème en décochant toutes les références, une à une, en compilant et en la recochant si la compilation se plantait.
Il semble qu'il y ai eu un sac de noeud entre les références Microsoft Office 11.0 Object Library et Microsoft Office 12.0 Object Library.
Par contre, je pense que la compil concerne le code VBA de l'application, et pas les évetuelles requêtes par assistant qui contiennent des fonctions non présentes dans ce code. Mais, peut-être, me trompe-je. Si je ne me trompe pas, j'attendrais qu'une requête par assistant se plante...
Néanmoins, je pense qu'une liste des fonctions avec, en regard, la référence dans laquelle Access va "taper" en fonction de la liste de priorité paramétrée serait une bonne chose : une liste des "Shift-F2" des fonctions, en quelque sorte.
Quoiqu'il en soit, merci beaucoup à vous,
Richard.
Pour connaitre la référence d'une fonction :
Clic droit sur la fonction, Définition (le F2 s'ouvre) dans le bas de la fenêtre tu as un lien composé de 2 mots séparés par un point.
tu clique sur le premier pour avoir le nom du fichier et son équivalent références.
Exemple :
Clic droit sur Val, puis définition, puis clic sur VBA (de VBA.Conversion).
C'est vrai que le VBE n'évolue pas autant qu'ACCESS et nous sommes nombreux à le déplorer.
Cordialement,
Bonjour loufab,
Oui, j'avais bien compris.
Mais il me semble judicieux d'obtenir une liste synthétique (que Access a forcément en mémoire) des liens fonctions/références, dans un sens ou dans l'autre, peu importe. De cette manière, nous saurions où va taper Access et pour quelle fonction.
A bientôt,
Richard.