il est
conseillé de faire un empaquetage et un redéploiement avec l'assistant
empaquetage et l'assistant installation qui placeront toutes les
librairies
nécessaires sur le disque.
il est
conseillé de faire un empaquetage et un redéploiement avec l'assistant
empaquetage et l'assistant installation qui placeront toutes les
librairies
nécessaires sur le disque.
il est
conseillé de faire un empaquetage et un redéploiement avec l'assistant
empaquetage et l'assistant installation qui placeront toutes les
librairies
nécessaires sur le disque.
Je n'ai pas utilisé beaucoup cet assistant mais j'ai l'impression qu'il
n'empaquete automatiquement *que* les dll qui sont références dans le
projet. Toutes les dll utilisées sans être référencées (du type Declare
Function aht_apiGetOpenFileName Lib "comdlg32.dll...) ne sont pas ajoutées
automatiquement.
Cela oblige à les ajouter manuellement, ce qui peut devenir assez
fastidieux
sur des projets assez lourds, utilisant pas mal de dll.
Je profite de ton post pour rebondir.
Dans le même registre, pour les dll qui sont ajoutées à l'empaquetage car
référencées dans le projet, que se passe-t-il si une version plus récente
est déjà présente sur le micro. On a le message d'avertissement ?
Enfin, comment sont gérés conflits ADO, DAO, etc... Quand on est sur un
poste disposant d'Access en version complète, il suffit d'aller
manuellement
faire le point dans les références. Sur un poste en runtime, comment gérer
le problème ?
Est-on obligé d'ajouter une routine chargée de faire l'inventaire des
différentes dll/ocx référencés, de les comparer avec celles présentes sur
le
micro et modifier les références si besoin ? Il me semble que Wooba avait
ajouté quelque chose dans le genre à son NakeData.
Je me souviens d'un poste de Pierre CFI qui m'avait un peu refroidit sur
l'utilisation du Runtime. J'utilise ce runtime depuis une période assez
récente (4-5 mois), sur une bonne dizaine de micros que je connais bien,
et
qui sont homogènes au niveau des dll présentes. Cela se passe bien, mais
je
me demande juste si l'utilisation de ce runtime peut s'envisager
"sérieusement" (;-)) à plus grande échelle, sur des micros dont on ne
maîtrise rien.
La solution est peut-être de :
* faire une routine qui recense tous les Declare Function pour ne pas
oublier de dll avant d'empaqueter.
* faire une routine qui règle automatiquement le problème des références.
Merci de ton opinion (les opinion des autres sont aussi les bienvenues !).
Salut Raymond,
Je profite de ton post pour rebondir.
Je n'ai pas utilisé beaucoup cet assistant mais j'ai l'impression qu'il
n'empaquete automatiquement *que* les dll qui sont références dans le
projet. Toutes les dll utilisées sans être référencées (du type Declare
Function aht_apiGetOpenFileName Lib "comdlg32.dll...) ne sont pas ajoutées
automatiquement.
Cela oblige à les ajouter manuellement, ce qui peut devenir assez
fastidieux
sur des projets assez lourds, utilisant pas mal de dll.
Je profite de ton post pour rebondir.
Dans le même registre, pour les dll qui sont ajoutées à l'empaquetage car
référencées dans le projet, que se passe-t-il si une version plus récente
est déjà présente sur le micro. On a le message d'avertissement ?
Enfin, comment sont gérés conflits ADO, DAO, etc... Quand on est sur un
poste disposant d'Access en version complète, il suffit d'aller
manuellement
faire le point dans les références. Sur un poste en runtime, comment gérer
le problème ?
Est-on obligé d'ajouter une routine chargée de faire l'inventaire des
différentes dll/ocx référencés, de les comparer avec celles présentes sur
le
micro et modifier les références si besoin ? Il me semble que Wooba avait
ajouté quelque chose dans le genre à son NakeData.
Je me souviens d'un poste de Pierre CFI qui m'avait un peu refroidit sur
l'utilisation du Runtime. J'utilise ce runtime depuis une période assez
récente (4-5 mois), sur une bonne dizaine de micros que je connais bien,
et
qui sont homogènes au niveau des dll présentes. Cela se passe bien, mais
je
me demande juste si l'utilisation de ce runtime peut s'envisager
"sérieusement" (;-)) à plus grande échelle, sur des micros dont on ne
maîtrise rien.
La solution est peut-être de :
* faire une routine qui recense tous les Declare Function pour ne pas
oublier de dll avant d'empaqueter.
* faire une routine qui règle automatiquement le problème des références.
Merci de ton opinion (les opinion des autres sont aussi les bienvenues !).
Salut Raymond,
Je profite de ton post pour rebondir.
Je n'ai pas utilisé beaucoup cet assistant mais j'ai l'impression qu'il
n'empaquete automatiquement *que* les dll qui sont références dans le
projet. Toutes les dll utilisées sans être référencées (du type Declare
Function aht_apiGetOpenFileName Lib "comdlg32.dll...) ne sont pas ajoutées
automatiquement.
Cela oblige à les ajouter manuellement, ce qui peut devenir assez
fastidieux
sur des projets assez lourds, utilisant pas mal de dll.
Je profite de ton post pour rebondir.
Dans le même registre, pour les dll qui sont ajoutées à l'empaquetage car
référencées dans le projet, que se passe-t-il si une version plus récente
est déjà présente sur le micro. On a le message d'avertissement ?
Enfin, comment sont gérés conflits ADO, DAO, etc... Quand on est sur un
poste disposant d'Access en version complète, il suffit d'aller
manuellement
faire le point dans les références. Sur un poste en runtime, comment gérer
le problème ?
Est-on obligé d'ajouter une routine chargée de faire l'inventaire des
différentes dll/ocx référencés, de les comparer avec celles présentes sur
le
micro et modifier les références si besoin ? Il me semble que Wooba avait
ajouté quelque chose dans le genre à son NakeData.
Je me souviens d'un poste de Pierre CFI qui m'avait un peu refroidit sur
l'utilisation du Runtime. J'utilise ce runtime depuis une période assez
récente (4-5 mois), sur une bonne dizaine de micros que je connais bien,
et
qui sont homogènes au niveau des dll présentes. Cela se passe bien, mais
je
me demande juste si l'utilisation de ce runtime peut s'envisager
"sérieusement" (;-)) à plus grande échelle, sur des micros dont on ne
maîtrise rien.
La solution est peut-être de :
* faire une routine qui recense tous les Declare Function pour ne pas
oublier de dll avant d'empaqueter.
* faire une routine qui règle automatiquement le problème des références.
Merci de ton opinion (les opinion des autres sont aussi les bienvenues !).
Salut Raymond,
Je profite de ton post pour rebondir.
Exact. ce que je faisais lorsque j'était en plein dans le système: je
faisais un empaquetage standard mais sans bases. en partant d'une base
vierge dans laquelle je cochais le maximum de mes librairies personnelles
et
le maximum des librairies "standards" microsoft. dans l'empaquetage je
supprimais les fichiers qui ne servaient à rien, tels que ma base. mon
empaquetage devenait donc un empaquetage de librairies et c'est tout. il
suffisait de le placer sur le Cd et de l'exécuter la première fois.
toujours placer DAO avant ADO et prendre le temps de remplacer les
database
par DAO.database. Access a obligatoirement besoin de DAO car certains
maniements d'objets réclament DAO
sur mon site j'ai des procédures de vérification des références utilisées
qu'on place sur le premier formulaire exécuté. mais si tu n'as pas le
fichier ça n'avance pas. il vaut mieux avoir le déploiement spécial dll
décrit ci-dessus.
à grande échelle sur des micros non maîtrisés, le runtime ne peut que
poser
des problèmes. d'où encore le retour au déploiement dll.
tout à fait d'accord pour la routine, on va s'y atteler, on a déjà des
bases
de départ avec la liste des fonctions utilisées dans les modules.
le problème des références, pour moi, est réglé sauf pour la dao car il
faut
la dao pour exécuter mais comme je mets toujours la dao dans mes
applications elle est toujours dans l'empaquetage.
je crois que j'ai fait le tour. on peut résoudre ce problème facilement si
on prend et on garde une organisation vba rigoureuse.
Exact. ce que je faisais lorsque j'était en plein dans le système: je
faisais un empaquetage standard mais sans bases. en partant d'une base
vierge dans laquelle je cochais le maximum de mes librairies personnelles
et
le maximum des librairies "standards" microsoft. dans l'empaquetage je
supprimais les fichiers qui ne servaient à rien, tels que ma base. mon
empaquetage devenait donc un empaquetage de librairies et c'est tout. il
suffisait de le placer sur le Cd et de l'exécuter la première fois.
toujours placer DAO avant ADO et prendre le temps de remplacer les
database
par DAO.database. Access a obligatoirement besoin de DAO car certains
maniements d'objets réclament DAO
sur mon site j'ai des procédures de vérification des références utilisées
qu'on place sur le premier formulaire exécuté. mais si tu n'as pas le
fichier ça n'avance pas. il vaut mieux avoir le déploiement spécial dll
décrit ci-dessus.
à grande échelle sur des micros non maîtrisés, le runtime ne peut que
poser
des problèmes. d'où encore le retour au déploiement dll.
tout à fait d'accord pour la routine, on va s'y atteler, on a déjà des
bases
de départ avec la liste des fonctions utilisées dans les modules.
le problème des références, pour moi, est réglé sauf pour la dao car il
faut
la dao pour exécuter mais comme je mets toujours la dao dans mes
applications elle est toujours dans l'empaquetage.
je crois que j'ai fait le tour. on peut résoudre ce problème facilement si
on prend et on garde une organisation vba rigoureuse.
Exact. ce que je faisais lorsque j'était en plein dans le système: je
faisais un empaquetage standard mais sans bases. en partant d'une base
vierge dans laquelle je cochais le maximum de mes librairies personnelles
et
le maximum des librairies "standards" microsoft. dans l'empaquetage je
supprimais les fichiers qui ne servaient à rien, tels que ma base. mon
empaquetage devenait donc un empaquetage de librairies et c'est tout. il
suffisait de le placer sur le Cd et de l'exécuter la première fois.
toujours placer DAO avant ADO et prendre le temps de remplacer les
database
par DAO.database. Access a obligatoirement besoin de DAO car certains
maniements d'objets réclament DAO
sur mon site j'ai des procédures de vérification des références utilisées
qu'on place sur le premier formulaire exécuté. mais si tu n'as pas le
fichier ça n'avance pas. il vaut mieux avoir le déploiement spécial dll
décrit ci-dessus.
à grande échelle sur des micros non maîtrisés, le runtime ne peut que
poser
des problèmes. d'où encore le retour au déploiement dll.
tout à fait d'accord pour la routine, on va s'y atteler, on a déjà des
bases
de départ avec la liste des fonctions utilisées dans les modules.
le problème des références, pour moi, est réglé sauf pour la dao car il
faut
la dao pour exécuter mais comme je mets toujours la dao dans mes
applications elle est toujours dans l'empaquetage.
je crois que j'ai fait le tour. on peut résoudre ce problème facilement si
on prend et on garde une organisation vba rigoureuse.
Je ne comprends pas bien ta réponse... Tu veux dire que le runtime ne peut
*que* poser des problèmes... si on *ne prends pas* les précautions
mentionnées ci-dessus. C'est bien ça ?
A ce propos, comment sais-tu qu'elle est dans l'empaquetage ? Puisque Dao
Si c'est le cas, comment savoir
quelles sont les dll qui sont ajoutées automatiquement par l'assistant,
sans
nous le dire ?
Salut Raymond,
Je ne comprends pas bien ta réponse... Tu veux dire que le runtime ne peut
*que* poser des problèmes... si on *ne prends pas* les précautions
mentionnées ci-dessus. C'est bien ça ?
A ce propos, comment sais-tu qu'elle est dans l'empaquetage ? Puisque Dao
Si c'est le cas, comment savoir
quelles sont les dll qui sont ajoutées automatiquement par l'assistant,
sans
nous le dire ?
Salut Raymond,
Je ne comprends pas bien ta réponse... Tu veux dire que le runtime ne peut
*que* poser des problèmes... si on *ne prends pas* les précautions
mentionnées ci-dessus. C'est bien ça ?
A ce propos, comment sais-tu qu'elle est dans l'empaquetage ? Puisque Dao
Si c'est le cas, comment savoir
quelles sont les dll qui sont ajoutées automatiquement par l'assistant,
sans
nous le dire ?
Salut Raymond,
REJe ne comprends pas bien ta réponse... Tu veux dire que le runtime ne
peut
*que* poser des problèmes... si on *ne prends pas* les précautions
mentionnées ci-dessus. C'est bien ça ?
oui c'est ça mais on n'est jamais à l'abri avec le runtime, faut pas
partir
sur du 100%A ce propos, comment sais-tu qu'elle est dans l'empaquetage ? Puisque
Dao
elle n'est jamais dans l'empaquetage car elle est diffusée automatiquement
dans le runtime. mais on oublie quelquefois de mettre le runtime et on est
marron. on peut toujours la rajouter manuellement, mais disons que ce
n'est
pas du sûr encore à 100%.
on pourra la mettre dans la routine à faire.Si c'est le cas, comment savoir
quelles sont les dll qui sont ajoutées automatiquement par l'assistant,
sansnous le dire ?
les dll rajoutées automatiquement sont du style mscomct2 lorsqu'on place
un
dtpicker par exemple. ça on peut le retrouver.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour une meilleure
efficacité de tes interventions sur MPFA
"snack" a écrit dans le message de
news:%Salut Raymond,
RE
Je ne comprends pas bien ta réponse... Tu veux dire que le runtime ne
peut
*que* poser des problèmes... si on *ne prends pas* les précautions
mentionnées ci-dessus. C'est bien ça ?
oui c'est ça mais on n'est jamais à l'abri avec le runtime, faut pas
partir
sur du 100%
A ce propos, comment sais-tu qu'elle est dans l'empaquetage ? Puisque
Dao
elle n'est jamais dans l'empaquetage car elle est diffusée automatiquement
dans le runtime. mais on oublie quelquefois de mettre le runtime et on est
marron. on peut toujours la rajouter manuellement, mais disons que ce
n'est
pas du sûr encore à 100%.
on pourra la mettre dans la routine à faire.
Si c'est le cas, comment savoir
quelles sont les dll qui sont ajoutées automatiquement par l'assistant,
sans
nous le dire ?
les dll rajoutées automatiquement sont du style mscomct2 lorsqu'on place
un
dtpicker par exemple. ça on peut le retrouver.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour une meilleure
efficacité de tes interventions sur MPFA
"snack" <snackz@free.fr> a écrit dans le message de
news:%23kP5ybRuDHA.2360@TK2MSFTNGP09.phx.gbl...
Salut Raymond,
REJe ne comprends pas bien ta réponse... Tu veux dire que le runtime ne
peut
*que* poser des problèmes... si on *ne prends pas* les précautions
mentionnées ci-dessus. C'est bien ça ?
oui c'est ça mais on n'est jamais à l'abri avec le runtime, faut pas
partir
sur du 100%A ce propos, comment sais-tu qu'elle est dans l'empaquetage ? Puisque
Dao
elle n'est jamais dans l'empaquetage car elle est diffusée automatiquement
dans le runtime. mais on oublie quelquefois de mettre le runtime et on est
marron. on peut toujours la rajouter manuellement, mais disons que ce
n'est
pas du sûr encore à 100%.
on pourra la mettre dans la routine à faire.Si c'est le cas, comment savoir
quelles sont les dll qui sont ajoutées automatiquement par l'assistant,
sansnous le dire ?
les dll rajoutées automatiquement sont du style mscomct2 lorsqu'on place
un
dtpicker par exemple. ça on peut le retrouver.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour une meilleure
efficacité de tes interventions sur MPFA
"snack" a écrit dans le message de
news:%Salut Raymond,
