Version imprimable
Bonjour à tous !
Je voudrais savoir si, dans le cadre d'une application multi utilisateurs, migrer les tables depuis ACCESS sur SQL SERVER avait une réelle utilité?
Actuellement, sur certains formulaires, l’exécution d'une requête peut prendre quelques secondes du fait notamment que la base soit fractionnée et l'utilisation de la bande passante du serveur.
Une migration sur SQL Server et une interface sur Access peut elle améliorer les performances de l'application?
Cordialement,
Thomas ;)
Bonjour,
Oui, considérablement si le projet est encore dans l'ancien format avec un ADP. (voir mon ancien tuto).
Sinon en, ODBC avec ADO Direct pourquoi pas mais là, il faut essayer car les performances ne sont pas seulement liées à Access.
Mais en lisant votre message, la lenteur que vous constatez est peut-être aussi due à autre chose comme les index manquants sur des champ, l'usage massif de fonctions de domaine, l'usage de requêtes avec des conditions Where basé sur des champs de formulaire, des sous-sous-requêtes etc...
Argy
En effet ce formulaire comporte une requête avec des conditions basées sur des zone de texte.. Merci pour vos précisions, je vais essayer de faire cette migration en "Test" et je donnerais mes impressions.
Bonjour
Pour gagner en performances, est-ce qu'il faut passer en projet adp, ou lier les tables de la base du serveur sql en utilisant ODBC est suffisant ?
Cordialement
Bonjour,
Un adp est un projet dédié SQL Server via MSAccess pour disposer de l'ensemble des fonctionnalités de SQL Server.
Donc il sera plus performant.
Si vous avez du code DAO dans votre projet,il devra être transcrit en ADO.
Argy
Merci beaucoup pour ta réponse, je savais et j’espérais aussi que tu réponds a ma question, car j'ai remarquer que tu est le spécialiste ici des projets ADP :)
Revenons a mon problème que je voudrais développer un peu
1-Je travail depuis des années avec des bases de données accde en frontale et mdb en dorsale et pas de problèmes
seulement une de mes applications (gestion pharmacie utilisation simultané sur 3 a 5 postes) deviens rapidement lente (au milieu de l'année) et moi qui espérait quelle le devienne vers la fin, car chaque nouvelle année mes logiciels débutent avec des bases mdb vierges
2-Juste pour tester le truc j'ai installer et configurer mon serveur sql en 2005 et en 2008 Express
3-je voulais convertir mon projet en projet adp, ça se bloque, alors j'ai créer un nouveau projet adp (vierge) et j'ai importé les autres objets de mon ancienne base (j'ai découvert que les requêtes il faut les recréer sur le serveur sql)
Aussi j'ai remarquer qu'on peut créer/modifier les tables et les requêtes directement depuis Access sans passer par Visual Studio et ça seulement dans la version 2005 de sql Server pas la 2008 (depuis Access 2007)
et c'est très très bien, quant a l'utilisation de la connexion des tables via odbc ne permet rien a part la liaison, donc le projet adp est nettement meilleur
seulement pour tester mon applications en adp il me faut beaucoup de temps pour modifier/vérifier tous les codes et recréer toute les requêtes, mais si vraiment la rapidité du traitement sera nettement meilleure, ça vaut le coup d'essayer
4-Reste un problème mon application doit toujours être liée en plus a 3 bases de données de logiciels tierces (2 en firebird, et 1 en access), et si on est en 2008, je doit lier 7 tables a l'exercice précédent (2007)
Mais pour l'instant, et a court terme, je doit revoir mon logiciel essayer de modifier sa structure, en modifiant quelques tables et requetes pour essayer d'aller plus vite
désolé pour ce lent discours et merci d'avance
eh bien, bon courage.
Il y a du travail en perspective.
Argy
Merci a toi aussi :)
Je crois que j'ai trouver la solution, puisque l'application en question est utilisé par mes clients depuis déjà 3 ans, et pour ne pas perturber son utilisation, je vais commencer par remplacer les codes d'accès aux bases de données tierces DAO par ADO, j'ai modifier quelques codes et le résultats et très convaincant, comme ça le passage a ADP sera plus facile
Cordialement
:ccool:
Argy