Discussion :

[LeMin]

Bonjour à tous,
La discussion ré activée récemment https://www.developpez.net/forums/d1...nd-sql-server/ m'ouvre de nouveaux horizons en ces temps de confinement
J'avais, en 2018, https://www.developpez.net/forums/d1...phone-android/ fait l'interface entre un site Joomla local hébergé sur un PC et une base access via ODBC, mais mon besoin aurait été résolu si les données avaient été accessibles via internet.

J'aimerais donc bâtir un petit projet Frontale/dorsale avec dorsale accessible via internet.
Voila ce que j'ai compris:
- si ma base est liée avec des tables sur SQL serveur, et que le serveur SQL est accessible via internet, mes données peuvent être partagées via internet.
- du coup, je ne peux plus directement (par ex) modifier mes requêtes comme je le faisait sous access, mais plutôt mettre des filtres et des conditions WHERE au niveau de l'appel des formulaires ou des états (comme je le fais bien souvent).

Alors voici mes questions:
- y a t il des solutions gratuites pour avoir une base SQL accessible en ligne ?
- j'imagine que je verrai mes tables SQL via ODBC (comme j'ai fait pour ma solution Joomla) ?
- a part les requêtes, y a t il autre chose a modifier au niveau développement VBA par rapport à un projet entièrement sous Access ?
- ma version Access (2007) suffit elle ou mieux vaut il avoir une version plus récente ?

Merci beaucoup pour vos réponses

[nico84]

Bonjour,

Je n'ai testé que cette solution, donc à priori la meilleure :

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é.

Voici en 2 mots les résultats de mes tests qui datent de 2016 (j'avais aussi access 2007) :
- j'ai pris un abonnement azur donc c'est pas cher mais pas gratuit
- il m'a été relativement facile de transférer les données de ma dorsale accdb sur sql server azur
- j'ai aussi réussi à connecter ma frontale locale à la dorsale web en recréant les liens de tables
- mes forms ont pour la plupart recours à des recordset qui sont directement des requetes sur les tables (la fenêtre doit donc charger toutes les données de la requete à son ouverture)
- à l'époque tout mon code était en DAO (depuis je l'ai migré en ADO pour utiliser un base sql server locale)
Au final les temps de réponse étaient catastrophiques et j'ai abandonné cette voie pour me diriger vers une prise de commande à distance

Pour avoir une chance de réussir il faut amha revoir toute l'ergonomie du projet ou s'il n'existe pas encore s'interdire toute fenêtre en lien direct avec une table ou vue. De plus tout le code VBA doit être en ADO.

A mon sens il vaut donc mieux utiliser autre chose qu'access car on perd tous les avantages de cet outil

J'espère ne pas être le seul à contribuer et te souhaite bonne chance

[LeMin]

Merci @nico84 pour ton retour d'expérience.
Moi qui fondait beaucoup d'espoir sur cette solution préconisée par @argyronet

y-a-t-il d'autres retours ?