Discussion :

[hobbes34]

Bonjour,

Je tourne depuis qq semaines dans les forums et je n'arrive pas à me dépêtrer de mon pb... Ainsi je suis désolée de vous embêter si la réponse a déjà été donnée: je l'ai vue, mais je n'ai pas réussi à la mettre en application...

J'ai développé une base de donnée sous access 2010 (NB: je me suis formée sur le tas, donc, je ne maitrise pas à fond la programmation VBA !).

Je dois déployer cette BDD sur des postes installés sous XP. J'y ai installé access runtime 2010 et j'ai suivi la procédure de argyronet pour empaqueter et publier ma base.
J'ai cependant un souci au chapitre 5.2.4.1 /"le package n'inclut et n'inscrit pas les bibliothèques référencées".

Donc, mes bibliothèques, notamment MsWorld.olb version 8.5 manquent sur les postes XP.
Premiere question: comment utiliser Visual basic 6 ou visual studio net pour empaqueter mes références? Visual studio est visiblement payant et le lien microsoft pour télécharger Visual basic 6 renvoit sur Visual studio...

Pour peu que j'arrive à empaqueter mes références (j'ai bien la liste entière de mes références avec leur localisation sur mon poste Windows7), ma question est la suivante: sur W7, le répertoire dans lequel les références sont situées est "Office14". Sous Xp, est-ce que les références se mettent dans office14 ou office11 ? Comment va se passer la prochaine ouverture de access 2003 sur mon poste XP après importation des références.
En fait, je ne comprend pas bien l'exemple de la modification du fichier setup.ini dans la procédure. Comment identifie-t-on le répertoire d'installation des références?

Je suis désolée pour mes questions de néophyte... Mais le déploiement de ma base de donnée est réellement la dernière étape de mon travail ... et mes collègues piaffent d'impatience de disposer de la base de données ...

Merci d'avance!
Céline

[argyronet]

Bonjour,

L'empaquetage des références peut-être opéré en créant une suite de packages successifs, le 1er étant celui de l'application et ses éventuels fichiers qui l'accompagnent, le second avec les DLL et autres OCX si necessaire.
La modification s'opère en modifiant le fichier INI qui cible les différentes chaînes d'installations à opérer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
[MSI]
MSI=\Files\FrontalComptoir14.msi
 
[ChainedInstall_1] 
TaskName=Installation des librairies
Path=\Files\MyLibraries\Setup.exe
TaskType=EXE
IgnoreReturnValue=0
 
[ChainedInstall_2] 
TaskName=PDF & XPS Macro complémentaire
TaskType=EXE
Path=\Files\PDF\SaveAsPDFandXPS.exe
IgnoreReturnValue=0
 
[Product]
ProductCode={FA3ADB6A-A3A9-48A4-8AD9-F7AA8EFB876C}
ProductName=Les comptoirs
ProductVersion=2.5.0
SkipLangCheck=1
 
[Display]
Display=full
CompletionNotice=Yes

Pour ce qui est de Word ou d'Excel, je ne pense pas (à vérifier) que tu sois autorisée à embarquer une telle référence sur le poste cible dans ton package et ce pour 3 raisons :

1. C'est une histoire de licence !
2. Comment ton utilisateur va faire pour visusaliser le docment d'un format dont il ne possède pas le logiciel pour l'ouvrir...?
3. Le principe est fortement déconseillé (On ne fournit pas l'autoroute avec l'achat d'une voiture)

Donc pour ton problème de Word, il va falloir te documenter avant de constuire quoi que ce soit si Word n'existe pas sur le poste cible...

En revanche, si ton souhait est de faire en sorte que la compatibilté Word soit assurée par ton application quel que soit le poste et donc que Word existe bien mais qu'il n'est pas dans la bonne version (et donc antérieure), il te faut modifier ton code affairant à la manipulation de documents Word en adoptant une technologie LateBiding.
En d'autres terme :

1. S'assurer avec gestions d'erreurs idoines que ton code est parfaitement opérationnel (oui oui !)
   
2. Enlever la référence à Word
   
3. Convertir toutes les constantes nommées en déclaration de constantes locales ou privées :
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   Const wrdGoToBookmark = -1
   Const wrdFindContinue = 1

4. Modifier le type de déclaration de tes objets Word
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   3
   4
   5
   6
   Dim oWordApp As Object 'Word.Application
   Dim oWordDoc As Object 'Word.Document
   'Etc...
       Set oWordApp  = CreateObject("Word.Application") 'New Word.Application
   '[...]
       Set oWordApp  = Nothing

Tu n'auras donc plus de souci de référence et tu n'aura pas besoin de te compliquer la tâche davantage...

Argy

[hobbes34]

Bonjour Argyronet

Tout d'abord, merci pour ta réponse.

Pour avancer point par point (je comprends vite, mais il faut m'expliquer longtemps...)

J'avais bien essayé de modifier le fichier setup.ini, de la façon suivante (extrait):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[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\BDDChantiers_Fille_V86_2010.msi
 
[ChainedInstall_1] 
TaskName=Installation des librairies
Path=\Files\MyLibraries\Setup.exe
TaskType=EXE
IgnoreReturnValue=0
 
[ChainedInstall_2] 
TaskName=PDF & XPS Macro complémentaire
TaskType=EXE
Path=\Files\PDF\SaveAsPDFandXPS.exe
IgnoreReturnValue=0
 
[Product]
ProductCode={BDC95087-A5A4-40C2-808C-468D05F93D2B}
ProductName=BDDChantier
ProductVersion=1.0.0
SkipLangCheck=1

Mais la question que je me pose est "quelles sont les références qui sont concernées par la commande 'installation des librairies'". Il doit bien y avoir un endroit où on dit qu'on a besoin de la dao360.dll et donc un endroit où on paramètre le code du setup.exe?


Coté Word, mon problème est bien de gérer la compatibilité entre les versions. J'ai compris que j'avais un peu de travail à faire à ce niveau pour faire du lateBiding.

Ce qui me perturbe maintenant, c'est que le message d'erreur que j'ai à l'ouverture de mon fichier en runtime, indépendamment de la référence incomplète ou rompue au fichier "MSWORLD.OLB" est "Fonction "Left" non définie dans l'expression", ce qui, pour moi, traduit une rupture de référence.
En faisant la liste des références utilisées dans ma Base de Données 2010, j'ai identifié que l'erreur pouvait venir (?) de la référence dao360.dll
Celle-ci existe dans mon projet 2010, mais j'ai vu qu'elle existait aussi (avec une version antérieure) dans le répertoire programFiles de mon poste en XP.
Comment se passe la cohabitation de deux références avec des dates de versions différentes?
Est-ce que mon problème a des chances d'etre résolu avec l'importation/installation de cette dll ??

Merci d'avance.
Céline

[argyronet]

Avec un projet Access 2010, normalement il ne faut plus utiliser DAO 3.6 mais Microsoft Office 14.0 Access Database Engine Object Library si tue veux pouvoir appeler du OpenDatabase au format accdx.
Pour ce qui est de DAO, tu dois l'embarquer dans un package que tu peux créer avec INNOSETUP par exemple.
L'outil générateur de package Access ne te permettra pas de choisir des composants partant du principe que tu vas ou non embarquer le Runtime mais 2010 et pas une autre version.

Si tu fais du LateBinding, tu n'auras plus de messages affairant à "MSWORLD.OLB".

Il faut que tu élabores ton plan d'attaque de façon structuré.
Coté package, juge que ce n'est prioritaire que pour les moins pressés.
Pour les plus pressés, installe le Runtime 2010 manuellement, copie ton ACCDE qui pointe sur la BDD dorsale du serveur et procèdes à des tests.
Si tout marche, tu peux envisager le package.
Sinon, tu as bien entendu ta clé USB avec toi avec les DLL et OCX manquants...

Conseil ++ Installe VMWare sur ton poste et installes-y XP, Seven et Vista (enfin les OS que tu rencontres) dans la même config que ton utilisateur ; tu pourras tester tout ce que tu veux avant de distribuer.

Argy

[hobbes34]

Bonjour argyronet

J'ai décoché DAO3.6 et j'ai activé, en contrepartie, Microsoft Office 14.0 Access Database Engine Object Library. Je pense que je trainais DAO 3.6 depuis que j'ai transferé ma base de access 2000 à Access 2010.

Je n'avais pas compris qu'on pouvait ouvrir en direct, une bdd au format accdx sous runtime. Je privilégie donc cette première étape, avant de chercher à créer un package...

Après avoir décoché DAO 3.6 (mais ne rien avoir fait sur msworld.olb: je n'ai pas encore travaillé sur mon pb de msworld et de technologie LateBinding), mon appli runtime lancée sous XP cherche à trouver la dll nommée msado15.dll

Est-ce que c'est un pb similaire à mon appel aux applications world? ou est-ce encore autre chose? J'ai remarqué que mon pc en XP possède un ficheir msado15.dll, mais bien sur, il ne s'agit pas de la meme version que celle qui est sur mon poste Windows7...

Est-ce que cette rupture de référence peut expliquer le message d'erreur que j'ai à l'ouverture de ma base, quand le formulaire de démarrage se lance:

Fonction "Left" non définie dans l'expression

Je suis partante pour une solution "clé usb" et copie des dll et ocx manquants, mais je ne vois pas où les installer pour ne pas écraser les dll antérieurs existants (j'ai peur de mettre la zizanie dans le système pour les autres appli faisant appel à ces fameuses dll en question!)

NB: je suis en train d'installer VMware

Merci!

[argyronet]

Si tu n'utilises pas ADO (Microsoft Data Access - ActiveX Data Objects), décoche tout bonnement la référence à ADO.
Tu n'en as aucune utilité et donc ton problème avec msado15.dll disparaîtra.

Argy