J'ai donc une MDB msaccess qui doit ouvrir d'autres MDB et exécuter un groupe de code qui comparera deux mdb d'accès à la recherche de différences de code, de requête diffs, etc. L'objectif étant de vérifier que tout MDB de production n'a pas été modifié du déploiement d'origine.
Mon problème est que bon nombre de ces applications d'accès ont des macros Autoexec et il n'y a pas de moyen simple d'appeler .OpencurrentTatabase sans exécuter la macro Autoexec.
Comment puis-je simplement ignorer la macro à l'aide du code?
Je sais que je peux tenir la touche Maj enfoncée. Je sais que je peux aussi activer et éteindre cette option.
5 Réponses :
C'est une solution sournoise mais ça marche pour moi.
Je fais un docmd.databaseRansfer acimport de la macro Autoexec.
Ensuite, je remplace l'autoexec avec un vide en utilisant Docmd.DatabaseRansfer AceXport
L'astuce est qu'une exportation sera DOCMD.TRANSFERDATABASE ACIMPORT,
"Microsoft Access", SsourcePath,
Acmacro, "autoexec", "autoexecsource"
DOCMD.TRANSFERDATABASE ACEXPORT,
"Microsoft Access", SsourcePath,
Acmacro, "Autoexecblank", "autoexec"
Je le fais à nouveau pour le deuxième MDB
DOCMD.TRANSFERDATABASE ACIMPORT,
"Microsoft Access", SdestPath,
Acmacro, "Autoexec", "AutoexecDest"
DOCMD.TRANSFERDATABASE ACEXPORT,
"Microsoft Access", SdestPath,
Acmacro, "Autoexecblank", "autoexec"
Ensuite, je peux faire toutes les comparaisons pour trouver des diffs entre les deux MDB sans déclencher les macros Autoexec depuis que je les ai importées et les remplacées
Puis je comparais les deux macros que j'ai importées, puis les exportez-les vers les bases de données.
DOCMD.TRANSFERDATABASE ACEXPORT,
"Microsoft Access", SsourcePath,
Acmacro, "autoexecsource", "autoexec"
DOCMD.TRANSFERDATABASE ACEXPORT,
"Microsoft Access", SdestPath,
Acmacro, "autoexecide", "autoexec"
Évidemment, cette solution ne fonctionne qu'avec VBA dans l'accès, mais cela fonctionne.
J'espère que cela aide quelqu'un.
L'objet DOCMD est accessible en tant que propriété de l'objet Access Application , de sorte que vous n'avez pas besoin d'utiliser VBA dans l'accès; Vous avez juste besoin d'une instance de l'objet de l'application .
Le code de code au démarrage peut ne pas être dans une macro Autoexec, il peut donc être sous forme de démarrage, vous voudrez peut-être envisager d'envisager de «appuyer sur programmation sur la touche de décalage» via API:
Une autre option Si vous avez accès à Modifier les macros Autoexec des bases de données que vous ouvrez: Définissez une condition à chaque étape de la macro qui spécifie Si vous n'avez pas la possibilité de changer ces macros, vous risquez peut-être mieux de suivre la solution de @ Chuckb. [application]. [UserControl] . En spécifiant cela, la macro-étape ne fonctionnera que si la base de données est ouverte par un utilisateur, et non par l'automatisation. Si la macro-étape a déjà une condition posée dessus, vous pouvez simplement mettre des parenthèses autour de celui-ci: (condition ancienne) et [application]. [UserControl] .
Ceci est une question ancienne, mais une autre façon de le faire serait d'utiliser l'argument / CMD CommandLline, et utilisez une instruction de commande dans le démarrage de l'application pour exécuter des routines de démarrage conditionnellement en fonction de la / cmd argument fourni. Cela ne fonctionnerait que avec un démarrage de commandes, cependant, pas via l'automatisation.
Une autre option: faites une renommée de la macro Autoexec dans votre code VB.
opencurrentDatabase ("Votre base de données")
DOCMD.RENAME "AUTOEXEC", ACMACRO, "TMP_AUTOEXEC"
ClosecurrentDatabase
Après avoir terminé votre action, renommez à nouveau à Autoexec ... et voila ....
Ne OPENCUCRENTDATABASE CAUSEZ-VOUS L'Autoexec Macro à exécuter ( Avant Le Docmd.Rename La ligne est atteinte)?