
Envoyé par
argyronet
Et pour terminer, la troisième solution qui reste à,la fois reconnue, stable et efficace avec de bonnes performances consiste à simplement lier vos des tables SQL Server à votre application frontale.
Cela vous permet de continuer à utiliser, appeler ou passer des paramètres à vos procédures SQL directement sur le serveur SQL via du code approprié avec des Command.
Vous conservez bien évidemment dans ce cas votre code VBA avec la technologie ADO.
Il vous faudra alors substituer votre projet ADP au profil d’une classique base de données Access sur laquelle vous attachez vos tables SQL Server avec le pilote idoine. De plus, ce choix vous permettra en parallèle de lier des tables d’une base dorsale Access qui pourra traiter des données issues des tables SQL Server à travers des requêtes action locales.
Le choix de cette alternative vous demandera de modifier quelques-unes de vos habitudes de développeur.
À titre d’exemple, le fait d’attacher une « Vue » SQL Server mais de ne pas pouvoir la manipuler avec des critères pourra vous permettre à passer une condition Where ou un Filtre (passé à l’argument d’un OpenForm ou OpenReport) et ce sans modifier l’objet source. De plus, cela sera traité avec de relatives bonnes performances.
Quant à la modification, maintenance ou création des vues et des procédures stockées, vous devrez faire appel à des outils propre à SQL Server, par exemple SQL Management Studio (SSMS) bien que cela prenne peut-être un peu plus de temps à élaborer et/ou concevoir qu’avec Access lui-même qui permet lui d’élaborer des requêtes-minute.
Cette dernière alternative reste de loin la moins coûteuse et la plus facile à mettre en œuvre pour vous d’un point de vue temps de refonte du projet, car vous conservez quasiment tout votre code existant et si vous maîtrisez Access, le temps de familiarisation sera minimisé.
Partager