pourquoi quand on distribue une application access, est-on à la merci des
configurations de machine cliente. J'ai une application frontale qui
contient diverses références à des DLL standards de MS. J'ai toujours cru
que l'ordre d'apparition des DLL dans la liste avait une certaine
importance. Donc pourquoi cela est il toujours à refaire à chaque mises à
jour qu'on déploie. Le problème est encore pire si on fait face à divers OS
ou version d'Access.
Y a t-il un "Comprendre l'ordre et la nécessité des DLL pour les pas trop
nuls"
J'ai ici dans ma frontale mais ce n'est pas toujours ce qu'on les
utilisateurs
-Visual Basic for Applications
-MS Access 9.0 Objects Library
-MS Visual Basic for Applications Extensibility 5.3
-OLE Automation
-MS DAO 3.0 Object Library
-MS ActiveX Data Objects 2.1 Library
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
"Ma Dalton"
pourquoi quand on distribue une application access, est-on à la merci des configurations de machine cliente.
Pas vraiment, a condition que tu crée un "empaquetage" qui apporte les biscuits nécessaire...
J'ai une application frontale qui contient diverses références à des DLL standards de MS. J'ai toujours cru que l'ordre d'apparition des DLL dans la liste avait une certaine importance.
Oui et non...
Donc pourquoi cela est il toujours à refaire à chaque mises à
jour qu'on déploie. Le problème est encore pire si on fait face à divers OS ou version d'Access.
Y a t-il un "Comprendre l'ordre et la nécessité des DLL pour les pas trop nuls"
J'ai ici dans ma frontale mais ce n'est pas toujours ce qu'on les utilisateurs -Visual Basic for Applications -MS Access 9.0 Objects Library -MS Visual Basic for Applications Extensibility 5.3 -OLE Automation -MS DAO 3.0 Object Library -MS ActiveX Data Objects 2.1 Library
Les problèmes peuvent survenir lorsque certaine "méthode" ou "objet" sont apportés par plusieurs bibliotèques (dll...)
Le plus frappant est le "DAO" et le "ADO" (deux derniers de ta liste) qui connaissent tous les deux l'objet "Recordset" (par exemple)
Pour contourner ces problèmes, nous conseillons depuis des lustres d'utiliser la forme suivante:
Dim rs As DAO.Recorset ensuite, tu utilise ton "rs" sur toutes les machines sans problèmes!
autrement dit: spécifier quelle méthode tu utilise...
Un conseil plus général: Utilise les API à la place des ActiveX et autre dll, même si elles sont signées Raymond ;-))
It's a Joke ;-)
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
Salut,
"Ma Dalton"
pourquoi quand on distribue une application access, est-on à la merci des
configurations de machine cliente.
Pas vraiment, a condition que tu crée un "empaquetage" qui
apporte les biscuits nécessaire...
J'ai une application frontale qui
contient diverses références à des DLL standards de MS. J'ai toujours cru
que l'ordre d'apparition des DLL dans la liste avait une certaine
importance.
Oui et non...
Donc pourquoi cela est il toujours à refaire à chaque mises à
jour qu'on déploie. Le problème est encore pire si on fait face à divers OS
ou version d'Access.
Y a t-il un "Comprendre l'ordre et la nécessité des DLL pour les pas trop
nuls"
J'ai ici dans ma frontale mais ce n'est pas toujours ce qu'on les
utilisateurs
-Visual Basic for Applications
-MS Access 9.0 Objects Library
-MS Visual Basic for Applications Extensibility 5.3
-OLE Automation
-MS DAO 3.0 Object Library
-MS ActiveX Data Objects 2.1 Library
Les problèmes peuvent survenir lorsque certaine "méthode" ou "objet"
sont apportés par plusieurs bibliotèques (dll...)
Le plus frappant est le "DAO" et le "ADO" (deux derniers de ta liste)
qui connaissent tous les deux l'objet "Recordset" (par exemple)
Pour contourner ces problèmes, nous conseillons depuis des lustres
d'utiliser la forme suivante:
Dim rs As DAO.Recorset
ensuite, tu utilise ton "rs" sur toutes les machines sans problèmes!
autrement dit: spécifier quelle méthode tu utilise...
Un conseil plus général:
Utilise les API à la place des ActiveX et autre dll,
même si elles sont signées Raymond ;-))
It's a Joke ;-)
--
A+
Pierre (3stone) Access MVP
~~~~~~~~~~~~~~~~~~~~~~~
http://users.skynet.be/mpfa
http://users.skynet.be/accesshome
pourquoi quand on distribue une application access, est-on à la merci des configurations de machine cliente.
Pas vraiment, a condition que tu crée un "empaquetage" qui apporte les biscuits nécessaire...
J'ai une application frontale qui contient diverses références à des DLL standards de MS. J'ai toujours cru que l'ordre d'apparition des DLL dans la liste avait une certaine importance.
Oui et non...
Donc pourquoi cela est il toujours à refaire à chaque mises à
jour qu'on déploie. Le problème est encore pire si on fait face à divers OS ou version d'Access.
Y a t-il un "Comprendre l'ordre et la nécessité des DLL pour les pas trop nuls"
J'ai ici dans ma frontale mais ce n'est pas toujours ce qu'on les utilisateurs -Visual Basic for Applications -MS Access 9.0 Objects Library -MS Visual Basic for Applications Extensibility 5.3 -OLE Automation -MS DAO 3.0 Object Library -MS ActiveX Data Objects 2.1 Library
Les problèmes peuvent survenir lorsque certaine "méthode" ou "objet" sont apportés par plusieurs bibliotèques (dll...)
Le plus frappant est le "DAO" et le "ADO" (deux derniers de ta liste) qui connaissent tous les deux l'objet "Recordset" (par exemple)
Pour contourner ces problèmes, nous conseillons depuis des lustres d'utiliser la forme suivante:
Dim rs As DAO.Recorset ensuite, tu utilise ton "rs" sur toutes les machines sans problèmes!
autrement dit: spécifier quelle méthode tu utilise...
Un conseil plus général: Utilise les API à la place des ActiveX et autre dll, même si elles sont signées Raymond ;-))
It's a Joke ;-)
-- A+ Pierre (3stone) Access MVP ~~~~~~~~~~~~~~~~~~~~~~~ http://users.skynet.be/mpfa http://users.skynet.be/accesshome
