I. Avant-propos▲
Ce document a pour objectif de satisfaire aux demandes des développeurs ayant besoin de déployer des applications développées avec Microsoft Access 2007.
Ce document a pour objectif de satisfaire aux demandes des développeurs ayant besoin de déployer des applications Microsoft Access version 2003.
Quatre autres tutoriels sont disponibles pour les versions 2000 ou 2002 (XP), 2003, 2010, et 2013 sur le forum.
Vous allez le remarquer pour la plupart d'entre vous, l'approche et le mode de déploiement des applications issues d'Office 2007 est différente bien qu'une certaine similitude avec l'outil d'empaquetage de Microsoft Access Developper 2003.
Une évolution intéressante est en place : l'empaquetage se génère désormais depuis le Menu Microsoft Office
I-A. Remerciements▲
Je tiens à remercier tout particulièrement toutes celles et tous ceux qui ont participé à la relecture de ce document en y incluant leurs remarques.
I-B. Contact▲
Pour tous renseignements complémentaires, veuillez me contacter directement (Argyronet) par MP.
II. Le développement de votre application (rappel)▲
Lorsqu'il vous est demandé de développer une application Access, la difficulté à laquelle vous risquez d'être confronté est la mise à disposition de celle-ci sur un ou plusieurs postes cibles. Au sein de l'entreprise dans ou pour laquelle vous travaillez, vous avez la responsabilité d'un ou plusieurs projets et de fait, vous participerez de près ou de loin à la mise en œuvre de tous les paramètres pour que vos applications soient opérationnelles.
Les informations contenues dans ce document considèrent le cas suivant :
- Vous développez une application à partir de Microsoft Office 2007 et bien entendu Microsoft Access 2007 ;
- Vous avez installé le Package Wizard qui est disponible depuis les outils d'installation de Microsoft Office ;
- Les postes clients possèdent ou ne possèdent pas une licence Access 2007 installée ;
- Vous travailler sur une plate-forme Windows XP SP3 ou Vista.
De nombreuses phases de test sont nécessaires avant d'envisager la mise en place sur les postes clients.
Ainsi, vous devez être à même de considérer trois cas de figure en ce qui concerne les applications.
Les applications simples
C'est ce que j'appelle des petites applications de bases de données où seul est prédominant le traitement des données. Les formulaires sont pratiques à utiliser, mais sans look particulier et sans grande convivialité (§ « Les Comptoirs » exemple fourni en standard), des états lisibles contenant les informations attendues et l'ensemble est géré de façon semi-automatique avec quelques macros ou quelques routines VBA.
L'utilisateur sera en face d'une interface un peu plus riche qu'avec les versions précédentes par la présence du Ruban Microsoft Office et du système de navigation grâce aux onglets et au Volet. Par ailleurs, les opérations courantes se limiteront à saisir manuellement un grand nombre de données pour aboutir à ses fins. Le tout fonctionnera en partie avec l'utilisation du Ruban sur l'interface Access en arrière-plan.
L'utilisateur pourra au gré de ses besoins, intervenir pour modifier ou créer des requêtes par exemple ou d'autres états à la condition que vous ne distribuiez pas un fichier compilé (accde ou mde).
Les applications avancées
C'est ce que j'appelle des applications semi-professionnelles de bases de données où est prédominant le côté convivial et « user friendly » de votre application. Le développeur aura conçu un projet propre, doté de fenêtres agréables, inclus des boutons pour automatiser les tâches et créé un Ruban personnalisé pour chaque formulaire.
L'utilisateur bénéficiera d'un confort d'utilisation très agréable avec de nombreux automatismes, des vérifications systématiques des entrées, des contrôles autoactivés en fonction des types de données saisis.
Les états auront un rendu très soigné, les ruptures des regroupements auront été vérifiées, etc.
L'application ne contiendra pas ou peu de macros et aucune pour les traitements des données.
Les applications professionnelles
Elles restent idéales et représentent le nirvana de l'application avancée. Elles sont dotées des caractéristiques totalement similaires aux précédentes, mais seront développées avec une finition irréprochable.
C'est une approche délicate, car le développeur doit oublier Access et considérer que son application est totalement indépendante.
Considérant la nouvelle interface de Microsoft Access 2010, le développeur se doit « d'oublier Access » et pour n'en détailler que quelques-uns :
- supprimer et remplacer les anciennes commandes de menu (DoMenuItem) même si elles restent compatibles (cas où la base de données est un MDB) ;
- exploiter totalement le Ruban Microsoft Office et non partiellement, e.g. en générant un nouveau Ruban personnalisé (voir Tutoriel de Tofalu à ce sujet) ;
- désactiver les fonctionnalités contextuelles ;
- masquer le Volet de navigation ;
- dans l'absolu, cacher l'instance Access pour ne laisser apparaître que l'application elle-même est un must auquel je me prêtais systématiquement dans les versions précédentes.
Avec cette nouvelle version et son Ruban, je serais tenté de dire que ce n'est plus un must dans le sens où si l'on souhaite exploiter le ruban et donner un look Office 2007 à votre projet, vous ne pouvez pas envisager ce choix.
Donc, quel que soit le type d'application que vous développerez, il est envisageable que pour leur distribution, vous soyez tenu de fournir un programme d'installation automatisé.
Il est vrai que pour le cas des applications simples, il est considéré que l'utilisateur possède une version complète de Microsoft Access 2007, la fourniture du fichier accdb par le biais d'un fichier d'installation automatisé peut paraître superflue. En fait, si vous n'avez aucun composant ActiveX externe (OCX) ou aucune référence à des bibliothèques particulières (DLL, TLB) et que tous les postes cibles (utilisateurs) sont équipés d'une version complète d'Access 2007, il suffit de distribuer simplement par copie, les fichiers (accdb ou accde).
Si votre application, quelle que soit la catégorie dans laquelle elle se range, utilise des composants spéciaux externes précités, vous devez faire en sorte que ces derniers soient fournis avec votre projet pour qu'ils puissent être inscrits dans la base de registre de Windows du poste client.
Notez que pour ce dernier cas et en particulier pour Windows Vista, les droits d'administration sont requis.
De plus, si vous envisagez de distribuer vos applications avec le Runtime Microsoft Access 2007, vous devez prendre en considération un certain nombre de paramètres. Ainsi, l'usage de la Solution d'Empaquetage et de Déploiement Access 2007 Developer Extensions désormais présent depuis le Menu Access lui-même, est là pour vous y aider même si vous pouvez envisager la distribution par un autre procédé.
Rappel :
si vous souhaitez empaqueter votre application à l'aide de
Microsoft Access 2007 Developer Extensions
, son téléchargement qui est
GRATUIT
est nécessaire.
Il n'est plus question d'acquérir une suite comme
Visual Studio Tools
(800 €) pour cela ce qui est une excellente chose.
Par ailleurs, l'utilisation ou la redistribution du Runtime Access 2007 est gratuite et que le nombre d'utilisateurs auxquels vous pouvez distribuer ce programme n'est pas limité.
Pour obtenir des informations au sujet de ces deux composants ainsi que pour leur installation, veuillez vous rendre à la section 3-1-1-1.
II-A. Les tests à effectuer avant de générer un fichier ACCDE ou ACCDR▲
Une fois le développement terminé, vous devez lancer une batterie de tests afin d'éliminer toutes les erreurs potentielles.
Le cas typique est souvent l'omission d'un formulaire de démarrage ou celle d'une macro AutoExec ou encore l'omission de certaines références vers des objets externes.
II-B. Test de l'application comme si elle était installée sur un poste client▲
Le jeu de tests consiste à exécuter l'application dans une situation identique à celle dans laquelle elle se trouvera après déploiement sur un poste…
II-B-1. …comme s'il était doté de la version complète Microsoft Access 2007▲
Il ne devrait pas y avoir de grande différence avec le poste de développement depuis lequel vous avez créé l'application.
Le jeu de tests consistera alors à naviguer entre les différents formulaires, l'impression des états (attention à l'orientation des états et aussi à la notion d'imprimante par défaut), à l'exécution de l'ensemble des tâches proposées par votre application.
II-B-2. …comme s'il était doté du Runtime Access seul sans version de Microsoft Access 2007▲
Du fait que certaines fonctions Microsoft Access standards sont masquées ou désactivées dans l'environnement Runtime, vous devez vous assurer que l'application fonctionne correctement dans cet environnement avant de la distribuer.
Pour simuler l'environnement Runtime pour votre application 2007, il suffit renommer votre fichier avec une extension accdr :
- dans le cas du projet abordé ici, l'application d'origine se nomme Mémots.accdb ;
- pour simuler son usage en environnement Runtime, son nom deviendra alors Mémots.accdr.
Pour obtenir de nouveau une version non verrouillée de votre application, il suffira de la renommer de nouveau avec son extension standard (si bien entendu elle est au format 2007).
Considérez ici que la situation est dédiée à se rendre compte comment se comportera votre application sur un poste client ne disposant d'aucune version de Microsoft Access, mais seulement celle du Runtime 2007.
Dans ce cas, il n'y a pas plus de procédures de test à effectuer que celles qui sont stipulées en section 2-2-1-1 ci-avant.
II-B-3. …doté du Runtime Access 2007 conjointement avec une version antérieure de Microsoft Access▲
Considérez ici que le poste client dispose d'une version de Microsoft Access antérieure (par exemple 2003) à celle du Runtime qui, lui, correspond à la version 2007 de Microsoft Access. Dans ce cas, vous devrez mettre en place une syntaxe particulière pour le raccourci que vous aurez à créer.
Bien que les bases de données et applications Microsoft Access 2007 possèdent une extension qui leur est propre (accdb, accde, accdr), il devrait, en théorie, ne pas être nécessaire d'avoir à créer des raccourcis spécifiques.
Pour autant, le fait que vous installiez une autre version de Microsoft Access représentée ici par le Runtime, celle-ci prend la main sur tous les types de fichiers reconnus comme des bases données Microsoft Access, à savoir :
- MDB / MDE / MDA
- ACCDB / ACCDE / ACCDR / ACCDA / ACCDT / ACCDC
- ADP / ADE
- MDW
L'énorme avantage de ces différences entre les extensions 2007 et les extensions des versions antérieures est que l'on peut différencier le programme à ouvrir selon le type de fichier sans avoir à créer forcément un raccourci.
Dans la mesure où l'utilisateur du poste sur lequel vous installez votre application 2007 avec le Runtime possède une version antérieure, vous pourrez lui apprendre à modifier les associations de fichiers depuis l'Explorateur de fichiers à partir du menu Outil/Options des dossiers.
MODIFIER LES ASSOCIATIONS POUR MICROSOFT ACCESS 2007
Dans l'onglet Types de fichiers, repérez les extensions caractéristiques des applications Access 2007 (accdb, accde, acccdr) et modifiez le programme pour les ouvrir :
Cliquez alors sur le bouton Modifier et sélectionnez le programme MSACCESS.EXE du dossier où est installé Office 2007.
Par défaut, il s'agit de :
C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE
S'il est présent dans la liste des applications disponibles, vous pouvez le sélectionner directement en repérant Microsoft Access 2007 par son icône caractéristique ; mais par acquit de conscience, il est préférable de cliquer sur le bouton Parcourir et de sélectionner le bon MSACCESS.EXE dans son dossier.
Vous cliquez enfin sur OK pour valider et répétez l'opération pour chacune des extensions concernées.
MODIFIER LES ASSOCIATIONS POUR MICROSOFT ACCESS VERSIONS ANTÉRIEURES (par exemple 97 à 2003)
De manière identique et toujours à partir de l'onglet Types de fichiers, repérez les extensions caractéristiques des applications Access 97 à 2003 (mdb, mde, mda) et modifiez le programme pour les ouvrir :
Cliquez alors sur Modifier et sélectionnez le programme MSACCESS.EXE du dossier où est installé Office selon les modalités suivantes :
C:\Program Files\Microsoft Office\Office\MSACCESS.EXE
C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE
C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE
Là aussi, vous êtes tenu de cliquer sur le bouton Parcourir pour aller chercher le bon MSACCESS.EXE selon la version installée sur le poste.
Dans notre exemple, il s'agit de Microsoft Access 2003 et vous sélectionnerez donc le dossier Office11.
Vous cochez alors la case intitulée :
Toujours utiliser ce programme pour ouvrir ce type de fichier
Vous cliquez enfin sur OK pour valider et répétez l'opération pour chacune des extensions concernées.
INSTALLER SUR UN POSTE VIRTUEL
Si vous ne disposez pas d'un poste de test, vous pouvez alors envisager d'installer sur votre propre poste un VMWare® ou bien Microsoft® Virtual PC 2004 qui vous permettra toutes les fantaisies en matière de simulation.
Vous devrez alors installer une version typique de Microsoft Office (97 à 2003) sur ce poste virtuel puis installer derrière votre application 2007 par l'intermédiaire de votre package.
Vous procéderez alors aux essais nécessaires et aux modifications à apporter en conséquence de ce qui vient d'être cité à propos des associations de fichier.
II-C. Comment et pourquoi convertir votre projet en fichier ACCDE ?▲
Un fichier ACCDE est à Microsoft Access 2007 ce que le fichier MDE était aux versions précédentes de Microsoft Access. À partir du moment où votre application Microsoft Access comporte du code Visual Basic, il est conseillé de l'enregistrer comme fichier ACCDE pour verrouiller votre projet.
Cette opération permet de compiler tous les modules et d'empêcher quiconque d'intervenir sur votre code source, celui-ci étant masqué ou de modifier la structure des formulaires et des états.
Parallèlement à cela, la base de données occupera moins de place sur le disque dur et le fait que le code soit compilé va augmenter les performances de l'ensemble.
II-C-1. Caractéristique d'un ACCDE▲
- Modification, création de formulaires, d'états ou de modules désactivés.
- Modification, ajout ou suppression des références aux bibliothèques d'objets ou aux bases de données interdites avec bien entendu, l'impossibilité d'intervenir sur le code à l'aide des propriétés ou des méthodes de Microsoft Access.
- L'importation ou l'exportation d'objets tels que formulaires, états ou modules est impossible.
- Seules les tables ou les requêtes peuvent être exportées ou importées vers ou depuis les bases de données.
Attention, avant de créer un ACCDE, compilez toujours votre projet à partir du menu Débogage de VBE .
Dans tous les cas, créez systématiquement une copie de sauvegarde de votre fichier accdb avant de procéder à la conversion en ACCDE et ce par sécurité. Notez qu'il est impossible d'inverser la compilation de accdb en accde, c'est-à-dire, de récupérer un fichier .accdb à partir d'un fichier .accde !
II-C-1-a. Précisions supplémentaires▲
Dans la plupart des cas, il est fortement recommandé de scinder votre application en deux bases distinctes à savoir une application frontale qui est le programme utilisateur et l'autre qui représente les données.
Que ce soit en utilisation locale ou en réseau, vous établirez une liaison entre l'application frontale et le fichier accdb contenant les tables.
Vous pouvez verrouiller l'accès à la base de données contenant les tables
En générant une version ACCDR de votre base de données, vous imposerez à quiconque d'ouvrir celle-ci en mode d'exécution.
Pour ce faire, modifiez simplement l'extension d'un fichier de base de données .accdb par .accdr. Vous obtiendrez alors une version « verrouillée » de votre base de données Access 2007.
ACCDR n’est pas une protection !
Notez que la modification de l'extension n'est pas une protection.
N'importe qui connaissant « le truc » peut changer l'extension afin de pouvoir accéder aux tables (dans ce cas précis).
Si l'utilisation est prévue pour être en réseau, vous poserez alors la base de données contenant les tables dans un dossier dédié sur le serveur et établirez la liaison avec l'application frontale depuis cette ressource réseau.
Les liaisons
sont inscrites en dur
dans l'application frontale.
Prenez donc en compte qu'il est fortement recommandé de générer le fichier ACCDE avec la liaison réelle des tables comme si vous étiez
sur le poste client sans quoi, aucune donnée ne sera disponible au moment de l'installation et une erreur sera levée.
J'entends pbasear
liaisons réelles
les liaisons
UNC
(
\\Server\Shared Path
) et non pas définies avec un lecteur mappé comme
H:\
,
P:\
ou encore
U:\
lettres communément employées dans les entreprises.
Dans les situations professionnelles dans lesquelles je suis confronté, j'emploie systématiquement la sélection des liaisons avec les conventions UNC même si, les accès aux serveurs sont mappés, auquel cas, je recopie le nom depuis l'
Explorateur
soit à l'aide d'une fonction
maison
qui me renvoie le chemin UNC du lecteur passé en paramètre.
Liaison des tables Microsoft Access
Pour afficher ou modifier les liaisons de votre base de données, il vous suffit d'activer le Gestionnaire de tables liées depuis le bouton du même nom dans l'onglet Outils de base de données…
La boîte de dialogue fera aussitôt son apparition :
La distribution d'une application dont les données sont liées nécessite que vous preniez la précaution de travailler dans un contexte identique en mode développement. Dans mon cas ici, je sais que mon projet sera installé dans C:\Program Files\Mémots, donc, je m'arrange pour que ma base de données ne contenant que les tables se situe au sein du même dossier. J'y ferai alors référence par un rattachement dynamique ce qui fait que les liaisons ne seront jamais rompues.
II-C-2. Comment scinder ma base de données avec Access 2007 ?▲
Pour pouvoir scinder votre base de données en deux bases distinctes dont l'une ne contient que les tables et l'autre tous les objets de l'application, vous pouvez procéder de la façon suivante.
Méthode manuelle
- Effectuez au préalable une copie de votre application.
- Quittez votre application.
- Dans le dossier où sera stockée votre application, créez une base de données vide (ex. : Program Files\Mémots).
- Nommez cette base avec un préfixe vous permettant de différencier les deux bases de données (par exemple DB ou Data).
- Depuis cette base de données vierge, importez toutes les tables de votre application actuelle excepté celles devant rester locales.
- Refermez la base de données puis rouvrez votre application.
Vous pouvez alors supprimer toutes les tables de votre application que vous avez exportées après vous être assuré de leur intégrité.
Cliquez ensuite sur le bouton Access de l'onglet Données externes pour pouvoir établir la liaison avec l'autre base de données.
Dans la boîte de dialogue qui vous permet de sélectionner la nouvelle source de données, cliquez sur le bouton Parcourir et sélectionnez la base de données que vous venez de créer dans le dossier Program Files.
Le chemin complet et le nom de fichier doivent apparaître dans la zone de texte de cette même boîte de dialogue. Vous pouvez alors cocher la case appropriée nommée « Lier à la source de données en créant une table attachée », puis cliquez sur le bouton OK.
Dans la boîte de dialogue suivante, la liste des tables de la base de données fait son apparition ; vous les sélectionnez toutes puis cliquez sur le bouton OK pour valider.
Méthode automatique et assistée
Vous avez également la possibilité de procéder à cette séparation par un Assistant disponible dans Access 2007.
Remarque
Cet Assistant existait dans les versions précédentes de Microsoft Access.
Vous le trouviez dans le Menu Outils, il se nommait « Fractionner une base de données ».
Pour ce faire, cliquez sur le bouton Base de données Access depuis le ruban Outil de base de données, et suivez les instructions à l'écran…
Au sein de votre projet, vous retrouvez alors toutes vos tables à l'identique, excepté que l'icône de ces dernières se verra greffer une petite flèche bleue, symbole caractéristique d'une table Access liée.
Remarque
Dans le cas d'une liaison établie avec un autre type de base de données ou via ODBC, cette icône change d'aspect.
Vérifier, rétablir ou modifier les liaisons des tables
En admettant que vous ayez déjà établi une liaison avec une base de données externe comme il se doit, mais que celle-ci n'est pas située au bon endroit, vous pouvez réattacher les tables. Pour ce faire, utilisez le Gestionnaire d'attaches et vérifiez l'emplacement.
Si vous jugez nécessaire qu'il faille le modifier :
- sélectionnez toutes les tables concernées ;
- cochez alors la case « Toujours demander un nouvel emplacement » ;
- cliquez ensuite sur le bouton OK ;
- localisez la nouvelle base de données…
La liaison s'établira d'elle-même avec les nouvelles tables si peu que celles que vous avez sélectionnées soient présentes dans la base en question.
Si vous développez votre application en dehors de l'entreprise, il est probable que vous rencontriez une erreur au niveau de la liaison, car l'accès au réseau ne sera pas possible.
II-C-3. Création du fichier ACCDE▲
Pour générer votre fichier ACCDE et après avoir vérifié et compilé votre code, vous sélectionnerez dans le Ruban Outils de base de données le bouton « Créer ACCDE »…
La boîte de dialogue s'ouvre et Microsoft Access vous demandera de confirmer le nom du fichier pour le générer.
Par défaut, le nom proposé est celui du fichier .accdb, mais muni d'une extension .accde.
Remarque
Une fois que vous avez cliqué sur le bouton Enregistrer pour créer votre fichier, l'application originale, c'est-à-dire celle avec l'extension accdb se recharge aussitôt après.
Donc, prenez les précautions qui s'imposent pour empêcher l'exécution de certains processus automatisés tels que par exemple la macro AutoExec.
Vous pouvez ici changer le dossier dans lequel vous souhaitez créer le fichier ACCDE. Par défaut, ce dossier est celui où a été créée l'application.
Remarque
Vous ne pouvez générer un fichier .accde qu'à partir d'un fichier Microsoft Access 2007.
Si vous ouvrez un fichier d'une version antérieure, vous ne serez qu'en mesure de créer un fichier MDE.
En effet, Microsoft Access 2007 ajuste les contrôles du ruban en fonction de la version du type de fichier ouvert.
L'application est une version
|
L'application est une version
|
---|---|
|
|
II-C-4. Impossibilité de générer un fichier ACCDE▲
Comme je vous l'ai stipulé dans la remarque ci-avant, vous ne pourrez créer un fichier accde qu'à partir d'une version Microsoft Access 2007 de votre application.
Vous ne serez pas non plus en mesure de générer un fichier de type dans les cas suivants :
- La base de données est de version antérieure à Access 2007 (l'option n'existe pas) ;
- Une erreur de compilation dans le code est présente (référence de bibliothèque invalide, erreur de syntaxe, etc.).
Dans les deux images ci-après, vous avez un exemple caractéristique de deux messages précisant que la génération du fichier ACCDE n'est pas réalisable.
Sans en préciser la raison…
mais parfois, il vous la renvoie :
Je recommande donc à tous les développeurs d'envisager de mettre en place des gestionnaires d'erreurs dans la plupart des procédures et fonctions sauf dans certaines classes ou sous-procédures et certaines bibliothèques, mais également de poser les instructions Option Explicit dans toutes les pages de code.
II-D. Sécurisation de votre Projet▲
Ce petit chapitre sur la sécurité est loin d'être exhaustif. Un authentique article sur la sécurité irait beaucoup plus loin…
Cette section a pour seul but de vous montrer que la notion de sécurité doit être prise en compte de façon sérieuse.
II-D-1. Sécurisation de votre application▲
Si vous distribuez votre application à des utilisateurs qui disposent de la version 2007 de Microsoft Access sur leur PC, plusieurs précautions s'imposent pour protéger votre application, et ce dans le but d'empêcher les éventuelles modifications des objets et du code ou de perturber par inadvertance le fonctionnement de l'application.
Microsoft Access 2007 ne permet plus d'utiliser la sécurité de niveau utilisateur pour les bases de données au format 2007 (.accdb ou .accde).
En revanche, cette fonctionnalité est toujours disponible si vous ouvrez une base de données d'une version antérieure.
Cela signifie que si vous voulez bénéficier de la sécurité utilisateur comme dans les versions précédentes pour votre application, vous devez travailler à partir d'un fichier MDB et non d'un fichier ACCDB.
Vous pourrez alors cliquer dans l'onglet Compléments du Ruban dans lequel vous retrouverez les menus des anciennes versions de Microsoft Access.
Pour obtenir davantage d'informations à ce sujet, vous pouvez inscrire la rubrique HA01230187 dans l'aide de Microsoft Access 2007.
Vous pourrez dans ce seul cas sécurisez tous les objets de votre base de données à l'aide de l'Assistant Sécurité avec la même méthode que dans les versions précédentes de Microsoft Access.
Pour obtenir toutes les informations sur la compréhension et sur la mise en œuvre de la sécurité sous Microsoft Access, je vous recommande de lire le tutoriel de Fabrice Constans.
En dehors de cela, pour sécuriser votre application, il vous faut :
- configurez toutes les propriétés de démarrage de la base de données susceptibles de permettre aux utilisateurs d'accéder au Volet d'Exploration et par la même au mode Création ;
- donnez à la propriété AllowBypassKey la valeur False pour désactiver la touche Maj. Cette précaution interdit aux utilisateurs d'ignorer les propriétés de démarrage ou la macro AutoExec.
Vous trouverez un exemple illustré pour paramétrer la propriété AllowBypassKey par le biais de Visual Basic en cliquant ici;
- protégez le code Visual Basic par un mot de passe (environnement VBE, Menu Outils, Propriétés de Votre projet, onglet Protection).
Si vous choisissez de mettre en œuvre la protection de votre projet avec la propriété AllowBypassKey, prévoyez pour vous-même une possibilité de désactiver celle-ci sans quoi, vous ne pourrez plus accéder (facilement) à votre application. Par exemple, vous pouvez ajouter un bouton caché dans un formulaire qui permet de passer cette propriété à True.
II-D-2. Les propriétés de protection d'une application▲
Il existe plusieurs propriétés dont vous pouvez écrire l'affectation par programme en VBA.
Parmi elles :
- - utiliser les touches spéciales d'accès (AllowSpecialKeys) ;
- - autoriser la vue du code sur erreur (AllowBreakIntoCode) ;
- - afficher la fenêtre de base de données (ShowStartupDBWindow) ;
- - autoriser les modifications des barres d'outils/menus (AllowToolbarChanges).
Pour configurer ces propriétés, cliquez sur le bouton Microsoft Office puis cliquez sur le bouton Options Access ou bien définissez ces options par programme en VBA.
Rappel
Si votre base de données contient du code Visual Basic, distribuez-le sous forme de fichier ACCDE. En effet, le fait d'enregistrer la base de données sous forme de fichier ACCDE a pour avantage de compiler tous les modules, de supprimer le code source et de compacter la base de données de destination tout en protégeant l'application de toutes modifications.
Donc, dans certains cas, si vous souhaitez laisser aux utilisateurs la possibilité de créer leurs propres formulaires ou leurs états, ne distribuez pas votre application au format ACCDE et ne verrouillez pas les options de démarrage.
Pour plus d'informations à propos de la sécurité de l'accès à la base de données elle-même, veuillez vous rendre sur le forum où toutes ces spécifications sont détaillées par Maxence Hubiche par exemple ici : Les clauses de sécurité Access.
III. Déploiement et empaquetage de votre application▲
Vous pouvez envisager deux cas de figure pour le déploiement de vos applications. La section déploiement expliquée dans ce document concerne les deux cas avec ou sans Runtime puisque finalement, le principe reste le même.
III-A. Préparation en vue d'exploiter l'application avec le Runtime Microsoft Access▲
Si vous souhaitez déployer votre application en vue d'une utilisation avec le Runtime Microsoft Access, quelques précautions sont à prendre :
- Que vous ayez, avant d'avoir compilé et enregistré votre application en .ACCDE, testé celle-ci en mode Runtime ;
- Que vous fassiez en sorte que le Runtime soit installé sur le poste utilisateur (cette option étant automatisable).
III-A-1. Préparation en vue d'exploiter l'application avec la licence Microsoft Access▲
Si vous souhaitez déployer votre application en vue d'une utilisation avec une licence Microsoft Access, vous devez vérifier que la version de Microsoft Access du poste utilisateur est identique à la vôtre.
III-A-1-a. Comment obtenir des outils nécessaires au déploiement de solutions Microsoft Access ?▲
Pour pouvoir bénéficier des outils nécessaires au déploiement d'applications Microsoft Access, vous pouvez télécharger « Access Developer Extensions » depuis le site de Microsoft en cliquant ici ou bien directement là.
Contrairement aux versions précédentes qui pour la version 2000 nécessitaient Microsoft Office Developer (voir Runtime 2000 ici) et pour la version 2003, Microsoft Visual Studio Tools (voir Runtime 2003 ici), l'outil d'empaquetage et de déploiement pour Access 2007 est GRATUIT !
Pour le Runtime Access 2007, c'est pareil.
Il est GRATUIT également et vous pouvez le télécharger depuis le site de Microsoft en cliquant ici ou bien directement là.
ATTENTION !
Ces versions sont actuellement exclusivement en anglais.
III-B. Installer Access Developer Extensions sur votre poste▲
Microsoft Access 2007 Developer Extensions est conçu pour les développeurs professionnels qui créent et souhaitent déployer facilement des applications Microsoft Access 2007. Il peut se coupler au Runtime Access 2007 permettant de distribuer des applications Microsoft Access sur des postes dépourvus de la version complète de Microsoft Access 2007.
Avant d'installer Microsoft Access 2007 Developer Extensions, prenez la précaution de quitter tous les programmes encore actifs et notamment Microsoft Access.
Cliquez simplement sur l'exécutable que vous avez téléchargé…
Confirmez alors l'exécution du fichier…
Puis cliquez sur le bouton Next…
Acceptez les termes de la licence d'utilisation et cliquez sur le bouton Next…
Confirmez alors l'emplacement proposé par défaut (recommandé) et cliquez sur le bouton OK
Ne tenez pas compte de ce qu'affiche l'image ci-dessus.
Le dossier 2007 n'existe pas sur votre poste. Le poste ayant servi à rédiger ce tutoriel possède plusieurs versions d'Office installées.
Puis cliquez sur le bouton Install
La barre de progression indique l'état d'avancement de l'installation (qui est très rapide).
L'installation est terminée par ce message :
Vous disposez donc de l'outil d'empaquetage dans votre version de Microsoft Access.
IV. Présentation de l'Assistant Empaquetage et déploiement▲
Cet outil n'est pas très différent de celui de la version 2003. Pour ceux d'entre vous qui l'ont utilisé, vous le constaterez rapidement.
Pour autant, il possède des fonctionnalités encore plus intéressantes.
L'outil servant à générer vos packages se nomme Package Solution autrement dit Assistant Empaquetage et Déploiement ; il est conçu pour vous aider à déployer des programmes d'installation de vos projets et applications Access 2007 par la génération de fichiers CAB & MSI et d'un programme d'installation (nommé Setup.exe) en vue de les distribuer.
Il a été relooké par rapport à la version 2003 et la mise en œuvre de packages en est facilitée.
Si vous savez que les postes clients ne disposent pas de la version complète de Microsoft Access 2007, cet assistant peut inclure le Runtime Microsoft Access 2007 de trois façons différentes :
- pas de Runtime : nécessite de Microsoft Access soit présent sur le poste ;
- par téléchargement si toutefois Access n'est pas installé sur le poste ;
- directement auquel cas il doit être disponible à un emplacement défini.
L'assistant regroupe tous les composants dont votre application a besoin pour fonctionner et automatise la plupart des tâches de création et de déploiement des fichiers tout en vous laissant la possibilité d'apporter les adaptations nécessaires pour les machines des utilisateurs finals.
V. Déploiement de votre application (avec le Runtime Access 2007)▲
Pour déployer vos applications avec un programme d'installation, installez Microsoft Access 2007 Developer Extensions.
V-A. Lancer L'Assistant Empaquetage et Déploiement (Package Solution)▲
Une fois Access Developer Extensions installé, cliquez sur le bouton Microsoft Office et repérez pour cliquer sur la commande Developer du menu…
puis de nouveau, cliquez sur la rubrique Package Solution.
V-A-1. Démarrage de l'Assistant Empaquetage et Déploiement▲
Dès que la fenêtre fait son apparition, vous avez le choix :
- de déployer directement dans le dossier proposé par défaut s'il s'agit d'une première utilisation sinon, le déploiement du package s'effectuera dans le dossier que vous aviez défini et sauvegardé comme dossier d'empaquetage par défaut lors de la précédente utilisation ;
- de déployer un modèle sauvegardé ce qui permet un gain de temps non négligeable surtout en ce qui concerne les éventuelles omissions quant à la sélection des fichiers à joindre à votre package
Le dossier par défaut est situé dans le dossier Mes documents :
C:\Documents and Settings\jp.ambrosino\Mes documents\Access Developer Extensions\Install Packages
V-A-2. Processus de déploiement▲
L'Assistant crée l'empaquetage et le programme d'installation (setup.exe) correspondant, en référençant tous les fichiers requis. À l'issue de cette étape, un ou plusieurs fichiers MSI et CAB vont être créés et accompagnés des fichiers d'installation associés.
Le déploiement d'une application consiste à transférer une application empaquetée vers le support de distribution choisi ou vers un site Web depuis lequel elle pourra être téléchargée. Pour distribuer votre application, vous avez plusieurs possibilités :
- l'enregistrer sur un support amovible, un lecteur local ou réseau ou encore un site Web ;
- vous pouvez copier manuellement les fichiers sur un CD-ROM ou sur partage réseau ou bien la publier manuellement sur l'emplacement Web approprié.
L'Assistant Empaquetage et Déploiement propose des raccourcis et exécute automatiquement certaines des tâches qui vous incombent dans la procédure manuelle de déploiement.
1. Déploiement sur un répertoire
Si vous optez pour un déploiement dans un répertoire, le système vous demande de choisir un répertoire local ou réseau dans lequel copier les fichiers pour qu'ensuite les utilisateurs puissent accéder au programme d'installation.
Par la suite, si vous souhaitez graver l'ensemble sur un CD-ROM, vous devrez utiliser un logiciel de gravure approprié.
2. Déploiement sur le Web
Vous pouvez, une fois votre package généré, envoyer votre empaquetage sur le Web via FTP par exemple.
Les fichiers et répertoires situés dans le répertoire local devront être enregistrés dans le répertoire Web avec la même arborescence que ce jeu de répertoires de base (en respectant la casse des noms de fichier - UNIX le requiert).
Dans le cas d'une installation directe via une page WEB dédiée, il est préférable de ne mettre à disposition que le fichier MSI qui a lui seul encapsule l'ensemble des fichiers nécessaires à l'installation, mais dépourvu du Runtime.
Il n'est pas possible d'exécuter le SETUP.EXE depuis le Web : cela génère une erreur traduite par l'impossibilité de trouver les fichiers requis - qui se téléchargent dans le dossier temporaire avec un nom suivi d'un [1] soit par exemple, setup[1].ini au lieu de setup.ini.
Si vous avez un grand lot de fichiers embarqués à la fois dans le MSI et dans des CAB, il est recommandé de générer un fichier compressé (ZIP ou RAR) autoextractible qui, par sa ligne de commande, lancera le Setup.exe.
Cliquez alors sur le bouton Suivant (Next).
La fenêtre suivante fait son apparition…
V-A-3. Choix du fichier à empaqueter▲
Contrairement à la version 2000, vous n'êtes pas tenu d'ouvrir le projet que vous souhaitez empaqueter.
Le choix s'établit à partir d'une liste déroulante qui contient tous les fichiers que vous avez déjà exploités auparavant ce qui, dans certains cas, vous permet une sélection rapide du fichier à empaqueter. Bien entendu, lors de la première utilisation, cette liste est vide. Vous pouvez remarquer que chacune des rubriques comporte une petite étoile rouge * qui signifie que la rubrique est obligatoire.
Pour plus de commodité, nous allons considérer que la fenêtre est composée de trois zones :
- la première zone détermine le nom du fichier et le répertoire d'installation ;
- la deuxième zone détermine si vous voulez inclure ou non le Runtime ;
- la troisième zone détermine les options du raccourci.
V-A-3-a. Sélection du projet à empaqueter (ici le projet Mémots)▲
Vous devez alors cliquer sur le bouton Parcourir afin d'aller chercher votre fichier dans le dossier correspondant.
Sélection du fichier de base de données ( Application frontale ) à empaqueter
Lorsque vous avez cliqué sur le bouton Parcourir afin de sélectionner le fichier que vous voulez empaqueter, vous pouvez choisir tout type de solution Microsoft Access ayant les extensions spécifiques qui les caractérisent.
Normalement vous êtes censés sélectionner un fichier de type ACCDE que vous auriez préalablement créé à partir de l'application elle-même et après avoir contrôlé son bon fonctionnement comme il se doit.
Pour pouvoir créer un fichier de ce type, reportez-vous à la section Créer un fichier ACCDE.
Au moment de la sélection du fichier, vous devez choisir celui qui fait office d'Application.
Pour ce qui concerne la base dorsale (si toutefois votre base est scindée) vous devrez l'inclure dans le package s'il s'agit d'une application vouée à être utilisée par une seule personne.
En effet, vous ne pouvez pas stipuler que vous souhaitez installer un ou plusieurs fichiers sur un lecteur réseau depuis l'Assitant, mais uniquement des sous-répertoires.
Il est dans bien des cas recommandé de mettre en place une routine de première utilisation qui se traduit par la mise en œuvre d'une fonction qui référence et installe les tables liées à l'aide de l'utilisateur.
Ici, toutes les fantaisies sont ouvertes :
- concevoir une table locale qui contient l'ensemble des tables liées ;
- inscrire le nom des tables dans un fichier INI ou dans le Registre ;
- […]
et mettre en place le jeu de fonctions idoines pour le rattachement dynamique des tables.
Dans notre exemple, l'application frontale s'appelle Mémot.accde et la base de données dorsale ne contenant les tables se nomme DBMémot.accdr, elles seront installées, pour cet exemple, dans le même dossier, à savoir %Program Files%\Mémots.
V-A-3-b. Choix du dossier d'installation▲
Vous pouvez déterminer le chemin initial d'installation du programme. Par défaut, il s'agit du répertoire de l'utilisateur de la session Windows.
Il peut être intéressant ici de changer ce dossier cible au profit de Program Files si vous installez sur un poste Windows XP et de laisser l'option initiale si vous installez sur un poste Windows Vista.
Vous déterminez ensuite le sous-répertoire. De manière générale, vous choisissez un sous-répertoire qui porte le nom de votre application.
Dans cet exemple je vais utiliser comme sous-répertoire Mémots.
V-A-3-c. Choix de l'inclusion du Runtime▲
C'est également ici que vous allez pouvoir déterminer si vous souhaitez inclure ou non le Runtime Microsoft Access 2007 selon trois options.
- Pour inclure le Runtime par téléchargement si Access n'est pas présent sur le poste de destination, vous devez cocher l'option 2 Require the Access 2007 Runtime.
- Pour inclure le Runtime depuis le fichier « AccessRuntime.exe » dont vous fournissez l'emplacement avec génération d'un fichier ACCDR, vous devez cocher l'option 3 Require nothing and install the Access 2007 Runtime.
Vous devez alors disposer de l'exécutable correspondant dans un dossier spécifique que vous préciserez.
Toute application ou tout programme Microsoft installés sur un poste de travail sont soumis à une licence. Bien que le Runtime Microsoft Access est gratuit et permet la distribution et l'exploitation de vos applications développées à travers un mode de fonctionnement équivalent à celui de la version complète de Microsoft Access, il n'en est pas moins doté d'une licence qui se traduit par l'acceptation des termes de celle-ci lors de l'installation du Runtime.
V-A-3-d. Détermination des options de raccourcis▲
Les options de raccourcis se définissent par 2 cases à cocher et 4 zones de texte :
- Start Menu : définit si vous souhaitez qu'il existe un raccourci dans le Menu Démarrer ;
- Desktop : définit si vous souhaitez qu'il existe un raccourci sur le Bureau ;
- Shortcut name : définit le nom que vous souhaitez donner à votre raccourci (pour qu'il soit plus parlant que le nom du fichier ACCDE) ;
- Icon : vous permet de sélectionner une icône pour votre raccourci qui est par défaut celle de l'application Access définie en fonction de l'extension ;
- Startup macro : vous permet de définir la macro qui doit être exécutée lors du chargement de l'application ;
- VBA Command value : vous permet de définir des arguments de ligne de commande via Command$ qui peuvent être lus lors du chargement de l'application.
Une fois toutes les options définies, la boîte de dialogue enrichie doit être similaire à celle ci-après
V-A-4. Sélection des fichiers à ajouter à votre package▲
La fenêtre de l'étape suivante se décompose en deux zones :
- la partie du haut concerne les fichiers que vous souhaitez inclure dans votre package
- la seconde à définir les options de clés dans la base de registre.
Fichiers supplémentaires
Si toutefois vous avez choisi d'inclure le Runtime dans le package, le fichier AccessRuntime.exe sera ajouté dans le dossier « Files » du package d'installation.
En revanche, les autres fichiers qui concernent plus particulièrement votre application, à savoir les fichiers d'aide, les éventuels documents annexes, les images, les icônes et tout autre type de fichiers dont votre application a besoin pour fonctionner ne sont pas prévus dans le package. Il vous faut alors les inclure manuellement en les sélectionnant comme vous avez sélectionné préalablement le fichier à empaqueter.
La fenêtre ci-dessous vous permet d'ajouter les fichiers supplémentaires :
- pour pouvoir ajouter les fichiers, il suffit de cliquer sur le bouton Ajouter (Add) et sélectionner, ensemble, les fichiers que vous voulez ajouter au package ;
- pour pouvoir supprimer un fichier qui a été ajouté à la liste, il suffit de cliquer sur le bouton Supprimer (Remove) une fois l'élément sélectionné dans la liste.
Une fois que vous avez sélectionné tous les fichiers à inclure avec votre package, ceux-ci apparaissent un à un dans la liste avec respectivement leur chemin source, leur nom et une zone dédiée à l'installation dans un sous-répertoire spécifique.
Lorsque vous sélectionnez les fichiers à inclure dans votre package, ceux-ci se trouvent dans un certain répertoire : par défaut, ces derniers seront installés dans le dossier de l'application, même s'il s'agit de composants tels que des bibliothèques ou assimilé. La source dans laquelle ils ont été puisés ne définit pas la destination, contrairement à la version de l'outil d'empaquetage 2000 que, de loin, je considère être le mieux conçu, en tout cas sur ce point.
En parallèle à cela, vous pouvez définir des sous-dossiers cibles :
=> par exemple, définir que vous souhaitez stocker les fichiers d'aide dans le dossier .\Aide et/ou les images dans le dossier .\Images.
%Lecteur%\ %Dossier% \ %Nom du répertoire de votre Application% \ %Nom du sous répertoire%
Dans mon exemple, l'application Mémots utilise des sons de type WAV qui doivent être insérés dans un sous dossier : ici il est défini comme .\Sons.
V-A-4-a. Le package n'inclut et n'inscrit pas les bibliothèques référencées▲
Lorsque vous empaquetez une solution Microsoft Access 2010, la base de données devrait être accompagnée de ses dépendances (bibliothèques et composants utilisés par votre projet), mais malheureusement, ce n'est plus le cas…
J'ai donc contacté Microsoft à Redmond pour tenter de solutionner cette régression au regard du véritable outil d'empaquetage de la version 2000.
En réalité, ce dernier était payant certes, mais efficace et véritablement professionnel ; avoir la gratuité du 2010 (comme celui du 2007 qui est dans le même cas) est très bien, mais cela l'est beaucoup moins si l'on ne peut déployer les composants qui accompagnent vos projets de façon native.
Il n'existe donc pas de solution à proprement parler autour de l'Assistant Empaquetage 2010.
Ainsi que je l'avais laissé entendre, le seul moyen de déployez les composants externes, même signés tels que le contrôle Calendrier 9.0 (MSCAL.ocx), mais aussi vos propres DLL ActiveX (celles que vous auriez développées ou celles développées par des tiers), vous devrez vous débrouiller pour les déployer et les inscrire (si nécessaire) par un processus externe dédié, en générant par exemple un package de déploiement spécifique.
Pour ce faire, vous pouvez utiliser un outil d'empaquetage comme celui fourni avec Visual Basic 6.0 ou bien celui disponible dans avec Visual Studio .Net 2003.
V-A-4-a-i. Comment mettre en place un autre package ?▲
Pour mettre en place un package dédié au déploiement des bibliothèques qui s'enchaîne avec l'exécution de l'installation du package Access 2010, vous devez modifier le fichier SETUP.INI présent dans le dossier Files\Setup du dossier généré par Solution de Package.
En dessous de la section [MSI], vous inscrivez une section nommée :
ChainedInstall_# où # représente un chiffre entre 1 et 9.
Je précise entre 1 et 9, car je n'ai pas pu obtenir le plafond du nombre de sections possible et je me permets de supposer que vous n'aurez pas plus de 9 packages à installer en chaîne pour une même application ou alors, il y a des petites choses à revoir dans votre projet.
Vous commencerez donc le nom de cette section avec le chiffre 1 s'il n'y en a qu'une, 2 pour deux et ainsi de suite. Dans l'exemple ci-après, je souhaite lancer deux programmes d'installation une fois que mon application sera installée, à savoir :
- Setup.exe chargé d'installer mes bibliothèques ; il est situé dans le chemin \Files\MyLibraries\
et
- SaveAsPDFandXPS.exe chargé d'installer le complément PDF/XPS de Microsoft ; il est situé dans le chemin \Files\PDF\
Les clés utilisées
TaskName : définit le nom de l'installation chaînée ;
TaskType : définit le type d'exécutable ;
Path : spécifie le chemin cible, à partir du dossier Files ;
IgnoreReturnValue : en cas d'erreur, mettez 1 si vous souhaitez continuer à installer les autres installations chaînées et 0 sinon.
___________________________________________________________________________________________________________________________________________
[MSI]
MSI
=
\Files\Memots.msi
[ChainedInstall_1]
TaskName
=
Installation des bibliothèques
Path
=
\Files\MyLibraries\Setup.exe
TaskType
=
EXE
IgnoreReturnValue
=
0
[Product]
ProductCode
=
{0CFFE9A1-5EB0-48A9-919F-979BE7AC4D9E}
ProductName
=
Memots
ProductVersion
=
1
.7
.4
SkipLangCheck
=
1
[Display]
Display
=
full
CompletionNotice
=
Yes
[Logging]
[MinOSRequirement]
VersionNT_1
=
501
WindowsBuild_1
=
2600
ServicePackLevel_2
[Cache]
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Les autres clés utilisables
CmdLine : permet de spécifier des paramètres au moment de l'exécution du package. Par exemple, /quiet lance une installation silencieuse.
Vous pouvez exécuter votre package manuellement avec le paramètre /? pour connaître l'ensemble des commandes possibles.
Reboot : si une installation chaînée nécessite un redémarrage, affectez la valeur 1 sinon ne spécifiez pas cette clé ou bien mettez 0.
L'installation chaînée suivante, si elle existe, reprendra une fois l'ordinateur redémarré.
V-A-5. Définition des propriétés générales de votre package▲
La fenêtre de l'étape suivante se décompose en quatre zones.
- General Properties :
Ce sont les propriétés générales. Vous définissez ici le nom du produit, la langue et le fichier contenant les clauses du contrat de licence de l'utilisateur final EULA.
Vous devez définir le langage utilisé par votre application. Vous ne pourrez pas cliquer sur le bouton Suivant tant que vous ne l'aurez pas spécifié.
Côté EULA, un fichier au format RTF doit être rédigé, il contient les informations relatives à la licence d'utilisation du logiciel ou de l'application. -
Feature Information :
Ce sont les informations sur l'installation personnalisée. Vous indiquez les mentions devant apparaître en cas d'installation personnaliséeUne installation personnalisée est une installation réservée en général aux personnes ayant un niveau de compétence avancé en matière d'informatique et plus particulièrement de Windows.
Elle donne droit à définir manuellement des paramètres qui sont définis par défaut par le Setup.
Chaque fois vous installez une application Microsoft, vous avez le choix entre différents modes : les plus courants étant Par défaut, Personnalisé et Minimum.Notez ici qu'il est exceptionnel d'avoir à définir des options d'installation personnalisée pour une application Microsoft Access.
-
Add/Remove Program Information :
Ce sont les informations devant apparaître lors de l'ajout de (composants) ou la suppression du programme. Vous définissez l'éditeur, la version du produit, la personne à contacter, les adresses Web de l'aide, du support en ligne et des mises à jour éventuelles et enfin les informations complémentaires relatives à ces éléments. - File Properties For Windows Installer Package : vous définissez les informations concernant le package du programme d'installation lui-même.
V-A-6. Définition des propriétés additionnelles de votre package▲
La fenêtre de l'étape suivante se décompose en trois zones.
- La première rappelle les informations sur l'installation personnalisée que vous avez spécifiées dans la fenêtre précédente.
- La seconde vous permet de définir de façon plus détaillée les informations concernant le package du programme d'installation : le titre, le sujet, l'auteur du projet, les mots clés et les commentaires.
- La troisième permet de définir une image pour l'accueil de l'écran lors de l'installation.
Les zones Product Code et Upgrade Code sont définies automatiquement par l'Assistant où un lien hypertexte vous permet de consulter ces informations.
Tous les éléments constitutifs nécessaires à la génération de votre package sont terminés ici.
Cliquez sur le bouton OK pour terminer.
V-A-7. Sauvegarde du modèle et génération du package▲
C'est ici la dernière étape et l'Assistant Empaquetage et Déploiement : elle vous propose de sauvegarder votre modèle dans le seul but de pouvoir le réutiliser.
Cette opération équivaut à l'opération de sauvegarde des scripts de la version 2000 de l'Assistant Empaquetage et Déploiement pour Office 2000.
La seule différence réside dans le fait qu'ici, le fichier généré est au format XML.
Le modèle sera sauvegardé dans le dossier suivant :
%Documents and Settings%\%Nom de l'utilisateur%\Mes documents\Access Developer Extensions\Saved Wizard Settings\%Nom du projet%.xml
V-A-8. Génération du package▲
Cliquez alors sur OK pour terminer.
Aucune fenêtre de fin de procédure ne fait son apparition.
Personnellement, je trouve qu'une petite barre de progression dans le formulaire aurait été appréciée.
Une fois généré, l'Explorateur de fichiers s'ouvre en vous présentant le dossier du package dès lors empaqueté et prêt à être installé ou déployé sur un autre support ou lecteur.
V-A-9. Vérification du package généré▲
Dans le dossier que vous avez défini se trouvent les fichiers nécessaires à l'installation de votre application.
Dans le sous-répertoire Files se trouvent les fichiers MSI et CAB de votre application ainsi que le Runtime si vous l'avez inclus à votre package.
V-A-10. Création d'un fichier AutoRun pour votre CD-ROM▲
Contrairement à la version de l'Assistant Empaquetage et Déploiement 2000, vous n'avez plus besoin de générer un fichier AutoRun manuellement pour votre package si toutefois vous proposez un CD-ROM d'installation.
En effet, cet Assistant génère ce fichier AutoRun.inf automatiquement pour vous, ce qui permet au programme d'installation d'être lancé automatiquement à condition que le Service de Notification d'Insertion de CD sur le poste client soit activé.
Ce fichier est à poser sur la racine du CD-ROM gravé avec votre projet.
V-A-10-a. Pour concevoir un fichier Autorun manuellement▲
Si toutefois vous souhaitez créer ou modifier un fichier Autorun, prenez un éditeur de texte comme Notepad ou autre et inscrivez-y au minimum les lignes de code correspondant à vos paramètres comme dans l'exemple suivant :
[autorun]
open = Setup.exe
icon = Mémots.ico
Il est bien entendu que le programme setup.exe tout comme l'icône Mémots.ico se situent sur la racine du CD-ROM si vous stipulez le contenu comme tel. Vous enregistrez ensuite ce fichier sous le nom Autorun.inf et l'incorporez dans la liste des fichiers de votre programme de gravure de CD-ROM.
VI. Évolution de votre package▲
VI-A. Gestion des modèles de l'Assistant▲
Lorsque vous travaillez avec l'Assistant Empaquetage et déploiement, vous pouvez créer et stocker des Modèles en cours de génération. Un modèle est un fichier XML dont l'extension est adepsws. Il contient les sélections et définitions que vous avez effectuées au cours d'une session d'empaquetage (ce que l'on a vu juste avant). Vous pouvez alors réutiliser un empaquetage lors de sessions ultérieures de l'Assistant pour le même projet.
L'utilisation des modèles assure des gains de temps intéressants.
Chaque fois que vous créez un empaquetage, il est recommandé de sauvegarder la procédure dans un Modèle.
VI-A-1. Avec cette option, vous pouvez effectuer diverses opérations▲
- Visualiser la liste de tous les modèles d'empaquetage générés.
- Renommer un modèle.
- Créer une copie d'un modèle sous un nouveau nom.
- Supprimer un modèle dont vous n'avez plus besoin.
Lorsque vous supprimez un modèle d'empaquetage, l'Assistant ne pourra plus générer de packages créés à partir de ce modèle.
Pour pouvoir le redéployer, vous devrez empaqueter de nouveau ce projet.
Veillez donc à ne supprimer que les modèles dont vous êtes sûr de ne plus avoir besoin.
VI-B. Modification ou évolution de votre projet▲
Il est très probable que vous ayez à faire évoluer certaines fonctionnalités de votre projet.
Dans ce cas, il faudra le redéployer sur le poste client si vous avez ajouté des composants ou référencé une DLL qui n'y figuraient pas dans la version initiale.
Ceci peut être un inconvénient, car il sera alors indispensable de désinstaller l'application initiale sur ledit poste.
En effet, si l'on souhaite travailler proprement, il ne faut ne jamais réinstaller une application sans l'avoir entièrement désinstallée d'abord.
On ne peut généralement plus désinstaller (proprement) une précédente application si plusieurs installations hétérogènes se sont succédé sans qu'elles aient été désinstallées d'abord.
Il est à noter alors que si votre client ou les postes concernés fonctionnaient avec le Runtime Microsoft Access, la désinstallation de l'application ne supprime pas le Runtime.
Sinon, il est vrai que dans 90 % des cas, la simple fourniture du fichier ACCDE (ou accdb si vous n'avez pas créé de accde) à copier dans le répertoire de destination est suffisante.
Là, vous pouvez donc procéder à la mise à niveau de votre application sur le poste client par la distribution à travers un petit VBScript ou un simple fichier .bat que vous rédigerez auparavant.
Cela reste la méthode de loin la plus rapide, surtout en réseau sur de nombreux postes tous identiques…
Sachez aussi qu'il existe des solutions de déploiement automatisées par le biais de logiciels spécifiques.
VI-B-1. Modification de votre projet▲
Si vous êtes amené à modifier votre application de base de données, il vous faut intervenir sur le projet accdb.
Vous ouvrez donc votre base accdb, apportez les corrections ou les suppléments nécessaires, protégez ensuite votre projet au niveau du code VBA même si le projet doit être compilé dans un ACCDE.
De là, vous enregistrez le tout pour enfin générer un nouveau fichier ACCDE.
Le nouveau fichier ACCDE que vous venez de générer, ainsi que tous les fichiers que vous avez modifiés (fichiers d'aide, images…), est censé être resté dans le répertoire source d'origine.
Si toutefois vous avez modifié un fichier quelconque dans un autre répertoire, il vous faudra le copier dans le dossier source de l'application afin de remplacer l'existant de manière à ce que l'Assistant Empaquetage et Déploiement le prenne en considération.
Tous les fichiers que vous modifiez dans ce répertoire doivent porter le même nom que les fichiers ayant été ajoutés au package.
Si vous ajoutez des fichiers non inscrits dans le modèle du package, vous devrez les ajouter manuellement lors de la session de l'Assistant Empaquetage et Déploiement, sans quoi, ils ne seront pas pris en compte lors de la génération du package, sauf si vous les inscrivez directement dans le XML.
VI-B-2. Réempaquetage de votre projet modifié▲
L'Assistant Empaquetage et Déploiement 2007 ne permet plus de régénérer rapidement vos jeux de fichiers CAB et MSI à partir d'un simple fichier Batch comme dans les versions 2000 et 2003, ce qui est fort dommage…
Pour régénérer un package, vous devrez alors lancer l'Assistant Empaquetage et Déploiement à partir d'Access 2007 comme pour une première utilisation, mais cette fois, en sélectionnant votre modèle que vous êtes censé avoir sauvé.
Ce fichier modèle doit porter le nom de votre projet ou plutôt celui que vous avez stipulé durant les étapes de génération de votre empaquetage.
Il possède une extension « .adepsws », dans mon exemple, il s'agit de mémot.adepsws.
Si vous avez modifié votre ACCDE au niveau des DLL et autres composants, il est indispensable de fournir un nouveau SETUP.EXE et non la simple copie du ACCDE mis à jour.
VI-B-2-a. Régénération du package après modification ou évolution▲
Pour pouvoir régénérer votre package, vous passez par le même menu depuis le bouton Microsoft Office…
Vous cliquez alors sur le bouton « Load wizard settings from a saved template file… » dans la mesure où vous avez sauvegardé le modèle, bien entendu.
Vous sélectionnez le fichier adepsws situé dans le répertoire proposé par défaut ou celui que vous avez choisi préalablement pour la sauvegarde.
Vous passez en revue les différentes étapes en apportant les éventuelles corrections, notamment sur la version et cliquez sur OK pour terminer…
Tout comme précédemment, l'Explorateur de fichiers sera affiché avec le contenu du package.
VI-C. Enregistrement de votre package sur une source d'installation▲
Lorsque votre package est prêt, vous pouvez le stocker sur une source réseau, un CD-ROM afin de faire en sorte qu'il puisse être installé sur un poste client. Vous pourrez également inclure d'autres fichiers par exemple Acrobat Reader pour le cas où vous fourniriez un guide d'utilisation au format PDF.
En tout état de cause, votre package doit contenir au minimum les éléments suivants :
- Setup.exe
Le dossier Files dans lequel se trouve le fichier MSI de votre projet et un dossier Setup qui contient un fichier INI correspondant.
(pour mon exemple Mémots.msi)
Le dossier Setup ne contient plus, comme dans la version précédente de l'Assistant Empaquetage et Déploiement pour Office 2000, les fichiers inclus dans le CAB.
Et si vous avez prévu de proposer l'installation du Runtime, le dossier Files contiendra alors :
- AccessRuntime.exe
- Et bien entendu, le fichier MSI de l'application à installer…
VII. Tester son programme d'installation▲
Une fois que vous avez terminé le processus d'empaquetage et produit des supports de distribution pour votre application, vous devez tester votre programme d'installation.
Pour ce test, choisissez une machine qui ne dispose pas déjà des fichiers de votre application ni des contrôles ActiveX requis par celle-ci. De plus, il est conseillé de tester l'installation sur différents systèmes d'exploitation.
Vous pouvez pour ce genre d'opérations, envisager d'utiliser des logiciels de machines virtuelles qui s'avèrent être d'un grand secours pour des simulations multiples et ce, à travers plusieurs systèmes d'exploitation.
VII-A. Pour tester votre programme d'installation depuis un CD-ROM ou un volume▲
- Insérez le CD-ROM dans le lecteur approprié…
ou bien,
- depuis le bureau, sélectionnez le menu Démarrer, choisissez Exécuter, puis tapez D:\setup.exe où D:\ est le lecteur source…
ou encore
- xliquez deux fois sur Setup.exe depuis l'Explorateur de fichiers.
VIII. Exemple d'installation sur un poste client▲
Si vous installez depuis un CD-ROM et que la notification d'insertion automatique est activée, la procédure d'installation automatique est lancée.
Sinon, vous devrez accéder manuellement et à partir de l'Explorateur de fichiers sur le CD-ROM ou depuis la source d'installation du disque dur ou du réseau et localiser le fichier SETUP.EXE.
VIII-A. Cas de figure où l'on souhaite installer le Runtime sur le poste▲
Pour le cas de figure qui suit, je suppose bien évidemment que vous avez embarqué le Runtime dans le package d'installation considérant que le client ne possède pas de licence Microsoft Access 2007.
Vous double-cliquerez alors sur le fichier Setup.exe et la procédure se lance aussitôt.
VIII-A-1. Étape 1 : Exécution du Setup▲
L'Installer va donc installer d'abord le Runtime puis l'application suivie de toutes les opérations de mise à niveau de Windows et notamment la base de registre…
Si vous avez sélectionné une image pour votre package, celle-ci est utilisée comme image de présentation :
La fenêtre spécifie ce qui va être installé…
Cliquez alors sur le bouton Next et acceptez les termes de la licence représentés par le fichier RTF que vous avez sélectionné durant la génération de votre package qui correspond à la zone de texte EULA.
VIII-A-2. Étape 2 : Coordonnées de l'utilisateur et de la société▲
À ce stade, vous seront demandés les noms et société de l'utilisateur ou plus précisément les informations relatives au poste de travail.
VIII-A-3. Étape 3 : Mode d'installation (Typique ou Personnalisée)▲
Choisissez ici le mode d'installation (Typique ou Personnalisée). Souvenez-vous, je vous l'ai précisé au moment de la génération du package, il est très exceptionnel d'avoir à définir une installation personnalisée pour une application Microsoft Access dont vous êtes l'auteur. L'option par défaut étant Typique, cliquez alors sur Typical.
VIII-A-4. Étape 4 : Démarrage de l'installation▲
Ici vous validez le lancement de l'installation. Cette étape étant la dernière, vous ne pourrez pas revenir en arrière après avoir cliqué sur Installer (Install).
VIII-A-5. Étape 5 : Progression de l'installation▲
La barre de progression indique le niveau d'installation et mentionne de temps à autre les différentes étapes du processus.
C'est le dernier moment où vous pouvez annuler la procédure en cliquant sur Cancel.
Dans ce cas précis, l'analyse détermine les éléments devant être installés, en l'occurrence ici, le Runtime…
Quelques bonnes secondes suffisent à achever l'installation…
VIII-A-6. Étape 6 : Fin de l'installation▲
Lorsque l'installation est terminée, cette première fenêtre s'affiche :
Vous cliquez alors sur OK et la fenêtre est remplacée par cette dernière :
VIII-A-7. Étape 7 : Repérage des éléments installés▲
VIII-B. Cas de figure où le Runtime ou Microsoft Access sont déjà présents sur le poste▲
Pour ce cas de figure, il est supposé que le Runtime ou bien une version complète de Microsoft Access tous deux de la version 2007, sont déjà installés sur le poste client. Il sera alors inutile d'inclure le Runtime dans votre package d'installation généré par l'Assistant Empaquetage et Déploiement, mais dans le doute, choisissez l'option 2 où le téléchargement est possible si le Setup détecte que son installation est nécessaire…
Dans tous les cas, c'est le programme du Setup qui se charge de déterminer s'il faut ou non installer le Runtime.
Rappel
Le Runtime 2007 ne sera pas installé si le Setup détecte une version existante de Microsoft Access 2007.
La procédure d'installation sera alors plus rapide et démarrera directement.
IX. Les tests à effectuer sur un poste de test▲
Une fois l'installation terminée, exécutez le programme installé pour vous assurer de son bon fonctionnement.
En général, vous n'êtes pas à l'abri de surprises inattendues et c'est le meilleur moyen de s'en rendre compte avant de délivrer le package à votre client ou à l'équipe d'utilisateurs de votre entreprise.
Veuillez alors revenir à la Section 2 relatant des tests préalables.
IX-A. Test de l'application installée sur un poste…▲
Le jeu de tests consiste à exécuter votre application depuis le poste sur lequel vous l'avez installé…
IX-A-1. …doté de la version complète de Microsoft Access▲
Il ne devrait pas y avoir de grande différence avec le poste de développement depuis lequel vous avez créé l'application.
Le jeu de tests consistera alors à naviguer entre les différents formulaires, l'impression des états (attention notamment à l'orientation des états et aussi à la notion d'imprimante par défaut), à l'exécution de l'ensemble des tâches proposées par votre application.
IX-A-2. …doté du Runtime Access seul sans aucune version de Microsoft Access▲
Si le poste client ne dispose pas d'une version complète de Microsoft Access, il semble évident que vous avez embarqué le Runtime dans le package d'installation SETUP.EXE. Le Runtime est alors résidant sur le poste client et se comporte comme si une version d'Access était installée sauf que celle-ci est dépourvue des fonctionnalités de conception.
Dans ce cas, il n'y a pas plus de procédures de test à effectuer que celles qui sont stipulées en section 9.1.1 ci-avant.
IX-A-3. …doté du Runtime Access conjointement avec une version différente de Microsoft Access▲
Ici, on considère que le poste client dispose d'une version de Microsoft Access antérieure à celle du Runtime 2007.
Dans ce cas, vous devez mettre en place une syntaxe particulière, car l'Assistant Empaquetage et Déploiement 2007 ne génère pas de raccourci approprié pour ce cas de figure.
Pour ce faire, soit vous le créez manuellement, accompagné des options de ligne de commande nécessaires pour démarrer Microsoft Access Runtime 2007 ou bien vous modifiez les associations de fichier comme cela a été spécifié auparavant…
Cas particulier pour un environnement réseau
Je vous déconseille en cas d'utilisation en réseau de mettre votre application frontale sur un serveur.
Outre le fait que dans ce cas, plusieurs personnes peuvent partager les mêmes formulaires et autres objets, les temps de chargement et d'exécution seraient horrifiques !
Vous devrez alors déplacer la base de données ne contenant que les tables sur le serveur dédié, car le setup ne saura pas le faire nativement… L'application frontale qui est liée à cette base sur chaque poste utilisateur sera installée dans le dossier Program Files ou dans le dossier du profil selon ce que vous avez choisi durant la génération du package…
Au début du document, je vous ai recommandé de travailler dans le contexte réel lors du développement de votre application, à savoir développer votre projet sur votre poste tout en ayant déposé la base de données décentralisée dans un dossier dédié sur le serveur s'il s'agit d'une application multiutilisateur ou dans le dossier Program Files\Nom de l'Appli s'il s'agit d'une appli monoutilisateur…
Toutefois, pour un confort de développement, il peut être préférable de travailler totalement en local et envisager de scinder la base de données plus tard lorsque le projet tire à sa fin dans sa phase de développement.
En cours de développement pour un cas de figure multiutilisateur, cela permet de se rendre compte notamment des temps de réponse de l'ouverture de certains formulaires exécutant des requêtes lourdes, ce qui permet alors d'envisager de les optimiser…
IX-A-4. …doté d'une version ultérieure à celle de l'outil d'empaquetage▲
J'aborde ici un sujet un peu plus délicat dans le sens où la version ultérieure à Office 2007 n'existera qu'en juillet 2010 donc dans un peu plus de deux ans…
Je ne vous cache rien en vous précisant ici que ce paragraphe a été écrit en 2010 justement, car il ne m'était pas possible de l'écrire avant du fait de ce que je viens de citer.
Donc si vous distribuez un package déployé avec Access 2007, qu'il soit composé du fichier MSI seul ou bien le lot complet (setup.exe), à un utilisateur dont le poste est pourvu de la version complète de Microsoft Access 2010 ou de son Runtime, vous serez confronté à la problématique de fournir impérativement le Runtime 2007 sans quoi, il sera impossible à l'utilisateur d'installer votre package.
C'est pour ma part une aberration sans commune mesure dans le sens ou les fichiers de type accd* sont du même format lorsqu'il s'agit d'Office 2007 ou 2010. La preuve en est que si vous ouvrez une base Access créée sous Access 2010, elle s'ouvre sans problème dans une version 2007.
Résumé des situations
- Si le poste est pourvu d'Access 2007 ou du Runtime 2007 => package 2007 (MSI) : Installation sans problème.
- Si le poste est pourvu du Runtime Access 2010 => package 2007 (MSI) : Installation impossible*.
- Si le poste est pourvu d'Access 2010 => package 2007 (MSI) : Installation impossible*.
Je ne pense pas que Microsoft apportera un correctif évolutif dans ce package…
Au moment où j'écris ce paragraphe, je rédige le tutoriel pour la version 2010 ce qui me permet de mettre à jour celui-ci présent. Ainsi que je l'ai écrit dans la version suivante, il est probable qu'un patch soit disponible pour l'outil de solutions de package 2010…
* Il vous faut fournir le Runtime 2007 avec votre package
IX-B. Erreur d'exécution au cours des tests▲
Vous n'êtes pas à l'abri de surprises en matière de bogues et d'erreurs concernant votre application nouvellement installée sur le poste de test. Si vous n'en rencontrez pas, tant mieux. Les plus courantes sont, en général, liées à une omission de la part du développeur vis-à-vis de l'application et son environnement.
IX-B-1. Quelques exemples▲
- Vous pouvez très bien voir une erreur qui se traduit par le dysfonctionnement d'un ruban personnalisé. Vous devez alors vérifier, selon la façon dont il puise sa structure (cas d'un fichier XML) qu'il est présent et opérationnel.
- Une autre sera liée à l'exploitation d'un composant qui n'a pas été enregistré sur le poste de test. Ce cas de figure peut se rencontrer quand vous avez greffé un nouvel ActiveX® dans votre projet, que vous avez créé le fichier ACCDE (ou le accdb) et fourni ou copié vous-même le ACCDE (ou le accdb) sur le poste de test sans avoir pris la précaution d'embarquer le composant et de l'enregistrer dans la base de registre de Windows du poste concerné… (Erreur 429).
IX-B-1-a. Erreur particulière : Utilisation impossible▲
Vous avez installé votre application avec succès et lorsque vous tentez de la lancer, un message apparaît :
« Actuellement, le système d'exploitation n'est pas configuré pour exécuter cette application ».
Bien que le message soit presque explicite, il faut avouer que Microsoft aurait pu faire un petit effort rédactionnel en spécifiant qu'il s'agit du fait que votre version de Windows XP doit impérativement être greffée du Service Pack 2…
IX-C. Création d'un formulaire de démarrage▲
Il existe deux cas de figure qui concernent l'obligation de créer un formulaire de démarrage :
- si aucun formulaire de démarrage n'est stipulé et que votre application est un fichier ACCDE ou un ACCDR rien ne se passera sinon l'ouverture d'une fenêtre bleue, absente de toutes possibilités sinon celles de fermer la base de données ou de quitter Microsoft Access ;
- si une macro AUTOEXEC est présente, elle se doit de spécifier l'ouverture d'un formulaire sinon, même phénomène que ci-avant se produira.
Il est donc conseillé de créer ce formulaire et parallèlement à cela, de stipuler que celui-ci doit être chargé au démarrage, qu'il soit Menu principal, Fenêtre de connexion ou Splash screen… Créer un formulaire de démarrage spécifique sous forme de «Splash Screen» permet d'obtenir un formulaire qui s'affichera de façon temporisée comme dans toutes les applications Microsoft au démarrage (§ Word, Excel…).
Ce dernier pourra par exemple se charger de vérifier un certain nombre de paramètres comme le chargement des Rubans avant d'ouvrir le Menu Principal.
Ceci dit, vous n'êtes pas tenu d'opter pour le choix des options qui définissent le Formulaire de démarrage. La mise en place d'une Macro AutoExec peut très bien faire l'affaire, mais dans tous les cas, un formulaire doit être affiché si votre projet tourne avec le Runtime.
Tout dépend des cas et des besoins.
IX-C-1. Spécification d'un formulaire de démarrage et des options de démarrage▲
La boîte de dialogue Option Access vous permet de définir le formulaire à ouvrir au lancement de l'application que vous avez développée.
Pour y accéder, ouvrez le menu Microsoft Office et cliquez sur la rubrique Base de données active…
Spécifiez les options comme ci-dessous où vous sélectionnez le nom du formulaire à démarrer (ici frmDemarrage)
Pour une sécurité totale, vous pouvez décocher toutes ou partie des cases, mais cela reste risqué si vous n'avez pas prévu le code pour les rétablir ou bien pour accéder à votre application en mode Création, par exemple avec un bouton caché ou une combinaison de touches particulière…
Sinon, nombreuses pourraient être les personnes qui posteraient sur le forum en écrivant qu'elles ont suivi ces conseils et que depuis, elles ne peuvent plus rien faire avec leur application…
IX-C-2. Exemple de formulaire de démarrage▲
Ceci est un formulaire de démarrage sous forme de «Splash Screen» pour l'application Mémots citée en exemple dans ce document.
IX-C-2-a. Génération d'un formulaire de démarrage temporisé▲
Pour concevoir un formulaire de ce type, en dehors de son contenu graphique, j'ai exploité l'événement Timer fixé à cinq secondes et parallèlement à cela, une routine se charge de faire quelques opérations de contrôle pour enfin afficher le formulaire Menu Principal.
Selon le type d'application distribuée, un formulaire intermédiaire comme une fenêtre de connexion avec Login et mot de passe peut être à prévoir…
Le Timer permet de temporiser une action. Dans ce cas précis, il permet d'afficher ce formulaire (présentant rapidement l'application chargée, histoire de faire patienter l'utilisateur) pendant cinq secondes avant de l'éliminer de l'écran et afficher ensuite le Menu Principal.
X. Installation du Runtime Microsoft Access sur le poste client▲
Vous avez deux manières d'installer le Runtime Access, l'objectif se limitant à pouvoir exécuter des applications Microsoft Access.
Il n'y a pas d'intérêt à installer manuellement le Runtime puisque lorsque vous générez un package d'installation qui embarque le Runtime, ce dernier est installé automatiquement. Mais j'ai personnellement été contraint de le faire sur quelques postes, c'est pourquoi j'aborde cette possibilité.
X-A. Installation manuelle▲
Vous pouvez télécharger le Runtime Microsoft Access 2007 directement et l'installer aussitôt.
Il est préférable d'en disposer une version locale tout de même…
Vous installez le Runtime Microsoft Access comme vous installez l'application Access elle-même sauf si vous n'y êtes pas autorisé (droits d'administration).
N'installez jamais le Runtime sur le poste développeur : cela est strictement inutile et resterait sans objet.
Si vous devez installer manuellement le Runtime sur plusieurs postes en réseau, je vous conseille de copier le fichier AccessRuntime.exe sur un serveur dédié et de lancer l'installation le Runtime depuis celui-ci.
Sinon, trouvez tout autre moyen de le faire (CD-ROM, clé USB, etc.) et lancez l'exécutable depuis le Répertoire en question.
X-B. Installation automatique du Runtime▲
L'installation automatique est quant à elle supervisée par le SETUP.EXE d'installation que vous empaquetez lorsque vous générez un package si vous avez coché les options 2 ou 3 des rubriques Access 2007 Runtime.
Voyez le chapitre consacré à la génération d'un package à l'aide de l'Assistant Empaquetage et déploiement, plus haut dans ce document.
X-C. Une fois le Runtime installé…▲
Une fois que les opérations d'installation manuelle ou automatique sont achevées, vous pouvez lancer une ou plusieurs applications Microsoft Access depuis un Raccourci ou depuis l'Explorateur de fichiers.
Rappel
Les associations de fichiers ADP/ADE/MDA/MDB/MDE des applications d'une éventuelle version précédente d'Access seront mises à jour automatiquement.
XI. Différences entre Microsoft Access et l'environnement Runtime▲
Il est impossible de lancer le Runtime en tant qu'application. Si vous tentez d'exécuter MSACCESS.EXE alors que ce dernier n'est pas la version complète, mais le Runtime (ils portent le même nom) vous recevrez un message d'erreur.
L'utilisateur ne peut pas accéder aux données dans la base de données autrement que par l'application elle-même. Il ne peut ni voir la structure des formulaires ni voir le code ou tout autre objet issu de l'application. Même si la base de données est située sur un serveur, l'utilisateur sera dans la même situation.
Si les applications qui fonctionnent avec le Runtime de Microsoft Access se comportent, à bien des égards, de la même manière que des applications qui fonctionnent avec la version complète de Microsoft Access (Microsoft Access Runtime est une version du logiciel Access ôtée des objets permettant la conception), il existe certaines différences qui peuvent avoir une incidence sur les approches de conception et de développement.
- Le Volet d'Exploration (équivalent à la fenêtre Base de données des anciennes versions) et Visual Basic Environment sont masqués.
- Les barres de Ruban intégrées ne sont pas gérées, mais vous pouvez néanmoins ajouter à votre application des barres de Ruban personnalisées.
- Certains menus (y compris les menus contextuels), fenêtres et commandes sont masqués ou désactivés.
- La gestion d'erreurs de Visual Basic est nécessaire. Les erreurs qui ne sont pas gérées par le code arrêtent l'application sans aucun avertissement préalable. Pour cette raison, l'emploi des macros est plutôt déconseillé.
Certaines séquences et combinaisons de touches sont désactivées :
Raccourcis clavier |
Correspondance |
---|---|
Ctrl+Pause |
Interrompt l'exécution du code ou de la macro |
Maj |
Empêche l'exécution d'une macro AutoExec et ignore les propriétés de démarrage des bases de données lorsque vous ouvrez une base de données |
F11 |
Affiche la fenêtre du Volet d'exploration |
F12 |
Affiche la boîte de dialogue Enregistrer sous |
Ctrl+G |
Affiche la fenêtre Débogage |
Ctrl+N |
Ouvre une nouvelle base de données |
Ctrl+Entrée |
Ouvre un objet en mode Création |
XI-A. Comment se présente le programme Runtime ?▲
Vous ne pouvez pas installer le Runtime Access 2007 sur un poste pourvu de la version complète de Microsoft Access 2007 tout simplement parce que le Runtime est installé dans le même répertoire que Microsoft Access.
il ne sera pas installé si cette version est détectée.
Par ailleurs, si une version antérieure complète de Microsoft Access (2000 ou XP ou 2003) est présente sur le poste devant recevoir le Runtime Access 2007, je vous préconise de procéder à des essais préalables, même si théoriquement, aucun conflit n’est intercepté excepté les associations de fichiers dans l'explorateur Windows.
XI-A-1. Tentative de lancement de Microsoft Access Runtime▲
Il n'est pas possible de lancer le programme MSACCESS.EXE puisqu'il s'agit de la version Runtime.
Il est impératif de spécifier une base de données pour pouvoir l'utiliser.
XII. Les erreurs liées à l'installation▲
XII-A. Erreur d'exécution 429 lors de l'exécution d'un programme Access▲
Symptômes
Vous installez une application d'exécution Microsoft Access Runtime ou bien vous exécutez une application Access et le message d'erreur suivant apparaît :
Erreur d'exécution '429' : Le composant ActiveX ne peut pas créer l'objet
Cause
Vous avez installé l'application d'exécution sur un ordinateur où Microsoft Access n'a jamais été préalablement installé. Cette erreur peut se produire lorsqu'un composant n'a pas été enregistré dans le Registre du système. En effet, lorsque vous introduisez dans votre application un certain nombre de références externes et que votre programme contient des instructions exploitant ces dernières via VBA, ce message apparaîtra et votre application ne pourra fonctionner.
Dans l'exemple de code ci-dessous, il est supposé que vous avez coché la référence à Microsoft Office 12 Access database engine Object ou DAO 3.6 Object Library.
Set
RS =
CurrentDB.OpenRecordset
(
"SELECT * FROM CLIENTS"
, DBOpenDynaset)
Résolution
Vous devez enregistrer correctement le ou les composants incriminés. Pour ce faire, vous devez localiser l'implantation physique de ces composants dans le système et également dans le registre de Windows.
Vous devez alors faire en sorte que le poste cible dispose d'une version qui corresponde à la version exploitée par votre projet.
Dans le menu Outils/Références de Visual Basic Editor, vérifiez si les références sont correctes (pas de terme MANQUANT) et que les références cochées correspondent bien à des bibliothèques correctement enregistrées (s'il ne s'agit pas d'un cas avec le Runtime).
Pour plus d'informations…
Pour plus d'informations, vous pouvez aussi jeter un œil ici à la page Résolution de l'erreur 429 lors de l'automatisation des applications Office.
XII-B. Erreur liée à l'utilisation de MouseWheel.dll▲
Dans la version 2007 de Microsoft Access, vous n'avez plus besoin de ce composant, car la molette est désactivée nativement.
En admettant que vous l'ayez tout de même utilisé par le fait que vous ignoriez cela, vous êtes tenu de fournir le composant MouseWheel.dll.
Comme nous l'avons vu juste avant, une erreur de type 429 est levée lorsqu'un composant ou une référence n'est pas correctement enregistré dans le registre de Windows.
Concernant l'exploitation de la DLL MouseWheel.dll, c'est un peu particulier.
Symptômes
Votre application fonctionne, mais bloque sur certains formulaires et vous ne pouvez plus rien faire, voire vous ne pouvez plus quitter l'application même si un bouton Fermer est disponible sur le formulaire.
En effet, si cette DLL n'est pas enregistrée correctement par l'installer SETUP.EXE issu de votre package ou bien si vous avez simplement omis de l'ajouter à la liste des fichiers :
- soit aucune erreur ne sera levée.
Cela est d'autant plus problématique que votre application va fonctionner à peu près, mais bloquera ou se comportera d'une façon inattendue dès que vous chargerez un formulaire qui contient le code VBA instanciant la classe MouseWheel ;
- soit vous recevez un message d'erreur typique à Microsoft Access.
Dans ce cas, vous ne pouvez rien faire puisse que ce message apparaît sur chaque mouvement de souris.
Vous serez alors obligé de jongler avec clavier et souris pour pouvoir retrouver la main et tuer le processus Microsoft Access depuis le Gestionnaire de tâches.
Cause
Ceci est tout simplement dû au fait que la DLL n'est pas enregistrée sur le poste où a été installée l'application.
Résolution
Pour remédier à ce problème, enlevez le code déclarant et utilisant ce composant et décochez la référence à MouseWheel.dll.
Réempaquetez alors votre projet afin de le redistribuer.
XII-C. Les projets accentués▲
Le projet empaqueté puise ses informations d'installation dans un fichier INI nommé setup.ini.
Si vous souhaitez modifier quelques paramètres, vous pouvez éditer ce dernier, mais il est préférable de régénérer un package via l'Assistant pour éviter les erreurs.
Il existe par ailleurs un bogue qui peut paraître surprenant.
Symptômes
Vous avez fini de générer votre package et au moment de l'installer, vous recevez cette erreur :
Cause
Il stipule que l'accès aux dossiers d'installation ne peut se faire.
En effet,il existe un caractère accentué dans la spécification du Dossier Parent du dossier \Files\ contenant les éléments de l'installation.
Jetez donc un œil dans le titre du message d'erreur ainsi que dans l'extrait du setup.ini ci-dessous et en particulier les clés MSI et ProductName :
; SETUP.EXE settings file.
[MSI]
; The MSI section gives the name of the MSI file to install. This file must be in
; the same folder as Setup.exe, and both must be in the root of the installation
; tree.
MSI=\Files\Mémots.msi
[Product]
ProductCode={259F9A19-4EFB-49BA-953B-882D52AF267E}
ProductName=Mémots
ProductVersion=1.0.0
SkipLangCheck=1
[Display]
; The diplay section is used for overriding the default UI
; Value Default Description
; Display full Option to override the default UI
; [none, quiet, basic, reduced, full]
; CompletionNotice Yes Option to display a setup completion
; notice for otherwise quiet setup
Display=full
CompletionNotice=Yes
Résolution
C'est un petit bogue qui sera certainement corrigé…
En effet, il n'existe pas d'accent en langue US.
En attendant, évitez les accents dans les noms des spécifications de votre projet et du dossier cible au cours de l'empaquetage ou bien modifiez le setup.ini en conséquence (peu recommandé).
XIII. Installation du Runtime Microsoft Access 2007▲
Vous pouvez installer le Runtime Microsoft Access sur un poste en particulier.
Le fichier AccessRuntime.exe est le fichier à lancer manuellement dans ce cas.
XIII-A. Installation du Runtime manuellement sur un poste▲
Tout comme vous avez procédé pour l'installation de Microsoft Office Access Developer Extensions, vous exécutez l'installation du Runtime Microsoft Access à partir du fichier exécutable.
Dans ce processus manuel d'installation, une fenêtre de confirmation de sécurité se fait voir afin que vous cliquiez sur le bouton Exécuter invoquant le fait que vous acceptiez d'exécuter ce programme.
Le jeu de fenêtres qui va apparaître lors de l'installation manuelle de Microsoft Access Runtime n'apparaît pas lorsque le processus d'installation du Runtime s'effectue par l'intermédiaire de votre package.
En théorie, vous n'avez pas à installer manuellement le Runtime sur un poste client.
Le but de vous montrer qu'il est possible d'installer manuellement ce Runtime pour se mettre dans une situation réservée à des fins de tests uniquement.
Dans l'idéal, il est évident que les tests effectués à partir du package d'installation restent évidemment les meilleurs.
Une fois que vous avez cliqué sur Exécuter, vous devez accepter comme à l'accoutumée, les termes de la licence pour pouvoir continuer…
Le processus d'installation est relativement court et se traduit par une simple petite fenêtre avec une barre de progression…
…suivie d'une dernière vous confirmant que l'installation est complétée.
XIV. Conclusion▲
Ainsi que vous avez pu le lire au cours de ces différents paragraphes, l'empaquetage de solution Access 2007 a été considérablement amélioré et simplifié.
Outre le fait que certaines fonctions présentes dans les versions précédentes (Batch), ne sont plus disponibles, la version 2007 possède d'autres compensations…