Discussion :

[LeMin]

Bonjour à tous,

Je développe actuellement des applications Access (Frontale sur chaque poste utilisateur et Dorsale sur serveur d'entreprise ou poste sous windows partageant un dossier) avec pas mal de VBA pour des clients. Pour éviter des problèmes de compatibilité, je développe actuellement en Access 2007, et mes applications tournent chez mes clients avec le runtime 2007 (Access2007RuntimeSp2Fr.exe).

J'aimerais me "mettre plus à jour", et je pensais passer sous access 2016 / et runtime associé.

Pensez vous que je m'expose à des problèmes ?
Merci pour vos avis et retours d'expérience.

[dumas.blr]

Bonjour Lemin,

Je suis confronté à une problématique équivalente, et je peux te dire que le passage de Access 2007 vers une version ultérieure pose quelques problèmes de compatibilité. En effet, il y a eu des modifications importantes à partir de Access 2010, ce qui fait que, lorsque j'ai voulu porter mon code vers cette plate-forme (et versions ultérieures), je me suis retrouvé confronté à de nombreux blocages VBA et erreurs de compilation.
Il te faudra donc effectuer une revue de code détaillée, surtout si tu a intégré des composants complémentaires (OCX, activeX, etc.)

De plus fais bien attention si tu passes d'une version 32bits à une version 64bits, car beaucoup de déclarations (les fameuses déclarations Declare Function ...) doivent être adaptées pour un portage 64 bits.

[marot_r]

Bonjour.

Si ton appli est "en pur" Access, mon expérience a été que généralement cela se passe bien.
Si possible reste en 32 bits, la version 64 bit est source de soucis divers et variés.
Un bon point avant de migrer est de s'assurer que l'appli compile sans erreur sur la version d'origine.

Au cas où tu ne serait 100% Acccess faire le tour des références avant de convertir.

Note que la conversion est un aller sans retour (ou presque mais ça peut être très pénible).

A+

[LeMin]

Merci beaucoup tous les 2 pour votre avis éclairé
@marot_r, je pense être en "access pur", et je suivrai tes conseils: de rester en 32 bits. Et j'ai pris l'habitude de compiler systématiquement avant de générer le .accde. Mais je dialogue "souvent" avec Word, ou Excel.

J'ai été confronté à 2 soucis de "compatibilité" précédemment, mais c'était entre Access et Excel:
1) l'entreprise a fait évoluer son office sur ses machines, passant d'office 2007 à plus récent. Excel2007 s'initialisait avec 3 feuilles vides, puis dans la version plus récente, avec uniquement 1 feuille: et comme je me servais de ces feuilles, une erreur a été générée.
2) L'application récupère des données issues de Excel dans une table Access: les libellés longs d'une colonne excel vont dans un champ "mémo". avec excel 2007 OK, avec excel 2016, les champs sont tronqués !
Avez vous déjà eu ce type de soucis ?

Au niveau de mes références, pratiquement toutes mes applications utilises les 4 listées ci dessous
- visual basic for application
- Microsoft Access 12.0 Object library
- OLE Automation
- Microsoft office 12.0 access database engine object Library

Et j'utilise plus rarement:
- Microsoft visual basic for applications extensibility 5.3
- Microsoft DAO 3.6 object library
- Microsoft Office 12.0 Object library
- Microsoft scripting runtime
- Microsoft Excel 12.0 object library
- Microsoft Word 12.0 object library

Au cas où tu ne serait 100% Acccess faire le tour des références avant de convertir.

Devrais je changer des références ?
Merci pour votre aide

[loufab]

Bonjour,
Je vois que tu utilises des bibliothèques externes au produit, notamment Office.

Je te conseille vivement de livrer en "last binding". En effet le "early binding" doit être réservé au seul développement, jamais à l'exploitation.

(PS: tu trouveras une solution pour ton problème de champ mémo sur mon blog)

Cordialement,

[LeMin]

Bonjour,
Je vois que tu utilises des bibliothèques externes au produit, notamment Office.
Je te conseille vivement de livrer en "last binding". En effet le "early binding" doit être réservé au seul développement, jamais à l'exploitation.

Merci @loufab pour tes explications sur le last_binding. Je vois dans mon code que je l'utilisais parfois sans le savoir !
Si je comprends bien, cela évite de cocher les références nécessaires.
Comment connait on la valeur des constantes necessaires à déclarer ? par ex

Code :

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

1
2
Const wdDoNotSaveChanges = 0
Const wdExportFormatPDF = 17

et si je comprends bien, il y a juste à changer

Code :

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

1
2
'Dim wApp As Word.Application   
'Dim oDoc As Word.Document

en

Code :

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

1
2
3
 
Dim wApp As Object
Dim oDoc As Object

Existe t il en VBA une déclaration conditionnelle pour commenter et décommenter automatiquement en fonction de la version dév ou opérationnelle ?

PS: tu trouveras une solution pour ton problème de champ mémo sur mon blog

J'ai vu cet article dans ton blog "Champ mémo et Export Excel, la galère"
Mon soucis était à l'import (Excel -> access) et dépendait de la version installée d'excel sur le poste (OK 2007, et KO 2016). J'avais bien vérifié à l'époque que le premier champ mémo avait plus de 256 caractères.
Est ce que ta façon d'importer réglerait le problème de version Excel du poste ?

[loufab]

Pour connaitre les variables à déclarer (uniquement celles utilisées) :

• Le F2 qui te donne nom et valeur en mode Early.
• Le F1 ou la doc MS qui est de mieux en mieux documentée.
• Les CHM Office dispo sur github.

Tu peux utiliser les syntaxes de compilation conditionnelle #if #else #endif pour alterner rapidement Earl/Last. Perso je ne l'ai pas fait et c'est un tort car ça à l'air pratique.

Export Excel : C'est le but du billet.

[LeMin]

Merci @loufab pour tes explications et compléments:
-F1, F2
- et ton blog très intéressant (je rajoutais toujours à la main "option explicit" alors que l'option dans l'éditeur est plus pratique)
Et merci @marot_r et @dumas.blr pour leurs messages.
Bonne fin de journée