Il est très simple d'attacher un "front-end" Access contenant des requêtes, des formulaires et des rapports à des tables de données stockées dans une base de données SQL Server. Il existe un outil appelé "Microsoft SQL Server Migration Assistant for Access" qui transfère une base de données Access existante vers SQL Server.
On peut toutefois se demander si vous en tireriez profit. Une "petite" base de données avec moins de 5 utilisateurs simultanés ne devrait pas avoir de problèmes de performance ou de fiabilité avec n'importe quelle version d'Access jusqu'à Access 97. J'ai personnellement plus de 200 installations d'un système Access multi-utilisateurs très complexe, dont beaucoup fonctionnent depuis plus de 10 ans, chaque installation comptant jusqu'à 25 utilisateurs simultanés, sans aucun problème particulier.
Cela dit, SQL Server est certainement plus résistant que le moteur Access, mais cela ne devrait pas être nécessaire pour le type de petite application que vous décrivez. Le seul vrai problème avec la fiabilité d'Access est la fiabilité du réseau. Des connexions au réseau interrompues ou incohérentes peuvent entraîner une corruption de la base de données, mais cette corruption est presque toujours facilement réparée en ouvrant le fichier de données dans Access et en lui permettant de se réparer automatiquement.
Les performances de SQL Server seront certainement meilleures avec des centaines d'utilisateurs simultanés, mais avec 5 utilisateurs, la plupart des fonctions seront tout aussi rapides, voire plus rapides, dans Access. Gardez à l'esprit que, même si 5 personnes ont l'application ouverte, le seul moment où elles transigent réellement avec la base de données est lorsqu'elles chargent des données dans un formulaire ou un rapport (en exécutant une requête) ou lorsqu'elles enregistrent les modifications apportées aux données. En observant leur travail, vous constaterez très certainement que deux actions simultanées sur la base de données ne sont pas si fréquentes.
Presque tous les problèmes de performance des applications Access sont dus à une conception incorrecte, en commençant par les structures de données et en poursuivant par une mauvaise conception des requêtes et des formulaires, l'utilisation de macros (jamais) et/ou un mauvais code VBA. La plupart des nouveaux utilisateurs d'Access ne sont pas conscients de la nécessité de diviser une application multi-utilisateurs en bases de données frontales et dorsales distinctes. Ce site article explique pourquoi cela est nécessaire et comment le faire. C'est assez facile - il existe même un assistant dans Access pour vous aider à le faire.
Si vous ne pouvez pas expliquer ou résoudre des problèmes de performance spécifiques à une application Access, vous devriez probablement demander de l'aide ici ou sur d'autres forums en décrivant la nature exacte du problème. Il existe également d'excellents livres, en particulier le Manuel du développeur d'accès par Ken Getz, et. al. Bien qu'assez ancien (2002), il s'agit de la "bible" de la conception d'Access et il est encore applicable à 99 % aux versions plus récentes.
Bonne chance !
