Bonjour,
J’ai une série d’applications « Front-end » Access 2002 ayant un comme « Back-end » une série de base de données Access tous liés les unes avec les autres. Par exemple, l’application A possède des tables liées avec l’application B et vice versa.

L’application est rendue à un stade où l’on doit faire un compactage et une réparation quotidienne en raison du volume et du niveau élevé de corruption. D’ailleurs pour être en mesure de faire fonctionner correctement les applications, je dois faire les modifications dans un environnement virtuel ayant les bons requis pour Access 2002 et ensuite réinstaller des « Access runtime 2010 - 32bits » et copier les fichiers Access (.mde) sur les postes qui sont eux en Windows 10.

L'option est une option temporaire (6 mois à 18 mois) car le client voudrait aller vers une solution complète avec base de données SQL. La solution étudiée est configurable et possède déjà un schéma de base de données SQL. J’ai déjà fait le test de transfert des formes, tables, requêtes et modules vers Access 365 mais j’ai des erreurs dans le code VBA. Toutes les règles d'affaires sont dans le code VBA.

J’ai déjà fait la proposition pour migrer les applications et les tables dans la nouvelle version de vers Access 365 et même SQL Server. Cependant pour l’instant je dois mettre l’application sur le respirateur artificielle et continuer le compactage quotidien jusqu’à ce qu’une décision soit prise.

En fait, pour être plus claire, je m’interroge sur la nécessité de modifier le front-end vers Access sachant que c’est une solution temporaire. J'aimerais trouver le « sweet spot » qui me permettrait d’effacer et continuer à le maintenir sans avoir à me soucier des corruptions car j’ai de la difficulté à voir un gain substantiel dans la migration vers le front-end Access 365. Qu’est-ce que vous en penser?

Quels sont les contraintes majeures aurait-il à migrer vers une base de données SQL sachant que l’application et le code VBA utilise la méthode DAO.