Discussion :

[adlinformatik]

Bonjour tout le monde
J'espère que j'ai posté au bon endroit
Je développe des solutions pour des PME/PMI depuis plusieurs années déjà, en utilisant Access, jamais eu de problèmes je le maitrise très très bien, je suis content et mais clients aussi, puisque tout fonctionne à la perfection, en client/serveur, ou en monoposte...
Sauf un, a cause de la quantité de données a traiter, au début c'était bien, mais avec le temps la quantité de donnée devient de plus en plus importante, aussi les taches a effectuer ont augmenté, sur le serveur, c'est rapide, mais sur les postes client parfois il faut attendre plusieurs secondes pour effectuer une opération !
Y a pas de cumul de données au fil des années, puisque mon application crée une nouvelle base de données vide chaque nouvel exercice, CAD chaque année, et je remarque qu'au début de l'année c'est bien, mais a partir de septembre ça devient de plus en plus lent !

Je pense que la solution est d'utiliser un moteur de base de données, au lieu d'une base accdb partagée
J'ai besoin de vos conseils pour choisir la meilleure solution, CAD un moteur qui soit rapide, moins gourmand en ressources et pas trop compliqué a installer
Je pense à MS SQL server Express, mais je ne sais pas trop
Merci d'avance

[binarygirl]

Il faut voir où se situe le goulet d'étranglement. SI la quantité de données devient conséquente, il faut peut-être revoir les index (en supposant qu'ils existent). Il peut y avoir de la latence au niveau des accès réseau aussi. Je ne pense pas que Access soit efficace pour distribuer les données sur un réseau à plusieurs utilisateurs.

Mais il faut voir aussi comment fonctionne le frontend. Si par exemple on rapatrie des tables entières pour alimenter des forms et des combo boxes côté client, alors oui, ces données doivent voyager à travers le réseau et partant du principe qu'il n'y a pas de caching, oui ça peut prendre du temps.

Il peut être intéressant d'utiliser un outil comme Wireshark pour sniffer le trafic entre un PC client et la DB distante, et évaluer le volume de données qui transite sur le réseau.

Je ne sais pas comment est structurée votre application. Mais si vous pouvez changer de DB facilement, alors je pars du principe que Access est juste une bête DB sans code fonctionnel. Essayer de mettre du logging dans votre application frontend, et faites une recherche sur les outils de profiling disponible. Il est important de localiser les parties du code où la lenteur se manifeste et comprendre le problème. Une fois le diagnostic posé, vous pourrez évaluer les options.

[nico84]

Bonjour,

J'ai migré mes bases de données access vers sql server express en 2012 et depuis ça marche beaucoup mieux : pas de bugs, pas besoin de compacter régulièrement...
Il faut bien sûr lier les tables à la base SQL et ensuite cela fonctionne tout pareil, sauf que certaines requetes peuvent devenir bien plus longues si elles sont mal traduites par le moteur JET d'access. En pratique il est donc préférable de réécrire toutes les requetes dans le code VBA en ADO (donc avec une syntaxe SQL server) et il peut être nécessaire d'alléger certains formulaires s'ils deviennent longs à se charger.

Il faut bien garder à l'esprit que
- JET / DAO (standard access) importe les données du serveur (parfois avec un grand nombre de requetes successives !) et exécute la requête sur le poste client
- ADO envoie la requete au serveur dans son langage (Oracle, SQL server, mysql...) et reçoit les données demandées en un seul paquet

Quoique 2 produits microsoft, le SQL d'access est très différent de celui de sql server

Bon courage

[adlinformatik]

Il faut voir où se situe le goulet d'étranglement. SI la quantité de données devient conséquente, il faut peut-être revoir les index (en supposant qu'ils existent). Il peut y avoir de la latence au niveau des accès réseau aussi. Je ne pense pas que Access soit efficace pour distribuer les données sur un réseau à plusieurs utilisateurs.

Mais il faut voir aussi comment fonctionne le frontend. Si par exemple on rapatrie des tables entières pour alimenter des forms et des combo boxes côté client, alors oui, ces données doivent voyager à travers le réseau et partant du principe qu'il n'y a pas de caching, oui ça peut prendre du temps.

Il peut être intéressant d'utiliser un outil comme Wireshark pour sniffer le trafic entre un PC client et la DB distante, et évaluer le volume de données qui transite sur le réseau.

Je ne sais pas comment est structurée votre application. Mais si vous pouvez changer de DB facilement, alors je pars du principe que Access est juste une bête DB sans code fonctionnel. Essayer de mettre du logging dans votre application frontend, et faites une recherche sur les outils de profiling disponible. Il est important de localiser les parties du code où la lenteur se manifeste et comprendre le problème. Une fois le diagnostic posé, vous pourrez évaluer les options.

Merci beaucoup pour cette réponse, je pense que je vais commencer par ça, avant de songer de changer de moteur de base de données je prendrai tout mon temps pour revivifier mon code, je pense surtout a désactiver quelques opérations, ou donner le choix a l'utilisateur des les activer ou pas, comme la journalisation, avant ils travaillaient normalement, après il y a eu beaucoup d'erreurs de la part des utilisateurs, alors ils ont demander de journaliser chaque opération, vente, paiement, modification de prix ou de quantité, suppression d'une ligne etc... Bien que ces informations soient très importantes pour moi, car quand les nouvelles recrues commettent des erreurs, c'est logiciel qu'on accuse !

Bonjour,

J'ai migré mes bases de données access vers sql server express en 2012 et depuis ça marche beaucoup mieux : pas de bugs, pas besoin de compacter régulièrement...
Il faut bien sûr lier les tables à la base SQL et ensuite cela fonctionne tout pareil, sauf que certaines requetes peuvent devenir bien plus longues si elles sont mal traduites par le moteur JET d'access. En pratique il est donc préférable de réécrire toutes les requetes dans le code VBA en ADO (donc avec une syntaxe SQL server) et il peut être nécessaire d'alléger certains formulaires s'ils deviennent longs à se charger.

Il faut bien garder à l'esprit que
- JET / DAO (standard access) importe les données du serveur (parfois avec un grand nombre de requetes successives !) et exécute la requête sur le poste client
- ADO envoie la requete au serveur dans son langage (Oracle, SQL server, mysql...) et reçoit les données demandées en un seul paquet

Quoique 2 produits microsoft, le SQL d'access est très différent de celui de sql server

Bon courage

Merci beaucoup
Si la solution proposé par binarygirl n'aboutit a rien, je change de moteur, et je comprends de ta réponse qu'il faut garder la frontale en Access, et juste changer la base de données
Aussi j'ai une petite remarque, quand tu dis : pas de bugs, pas besoin de compacter régulièrement
Je n'ai pratiquement pas ou plutôt plus de bugs, sauf la lenteur, et en ce qui concerne le compactage, pas besoin de le faire manuellement, j'ai développer un petit Exe en VB6 qui démarre avec Windows, et a chaque démarrage il vérifie la santé de la dorsale sur le serveur, et des frontales sur le serveur et les postes client, et il les compacte etc...
Donc pas de soucis de ce coté là

Et merci encore a vous deux

[nico84]

Pour info, il y a combien d'utilisateurs sur la même dorsale et quelle est la taille de cette dernière après compactage ?

[adlinformatik]

Pour info, il y a combien d'utilisateurs sur la même dorsale et quelle est la taille de cette dernière après compactage ?

La taille de la dorsale ne dépasse pas les 50 Mo, celle de 2022 est a environ 30 Mo
Le nombre d'utilisateur 5 ou 6 simultanément
Jusqu'ici tout parait bien
C'est un logiciel de gestion de ventes, achats, stock, situations etc
Pour la base de 2022 par exemple la table des entêtes des ventes au comptoir, contient 35000 lignes, celle des détails presque le double
La table des factures, les entêtes > 13000, les détails > 40000
Le nombre d'articles > 10000, avec le stock qui doit être mis à jour après chaque opération...
Le nombre de clients > 6000
Et beaucoup de chose encore
Je pense que le problème vient de là
Par exemple les achats ce n’est pas trop lent, la table entêtes contient > 2000 et les détails > 14000
Le nombre de fournisseur < 50
Aussi pour d’autres clients qui ont le même logiciel, et qui font a peu prés 50 % du chiffre d'affaire du client en question, ça fonctionne mieux, mais avec plus de lenteur a la fin de l'année

Merci

[tee_grandbois]

bonjour,

Aussi pour d’autres clients qui ont le même logiciel, et qui font a peu prés 50 % du chiffre d'affaire du client en question, ça fonctionne mieux, mais avec plus de lenteur a la fin de l'année

y a t-il des index sur les champs sollicités par les tris ou les filtres ?

[adlinformatik]

Merci pour la réponse

bonjour,

y a t-il des index sur les champs sollicités par les tris ou les filtres ?

Oui bien sûr

[nico84]

La taille de la dorsale ne dépasse pas les 50 Mo, celle de 2022 est a environ 30 Mo
Le nombre d'utilisateur 5 ou 6 simultanément
Jusqu'ici tout parait bien
C'est un logiciel de gestion de ventes, achats, stock, situations etc
Pour la base de 2022 par exemple la table des entêtes des ventes au comptoir, contient 35000 lignes, celle des détails presque le double
La table des factures, les entêtes > 13000, les détails > 40000
Le nombre d'articles > 10000, avec le stock qui doit être mis à jour après chaque opération...
Le nombre de clients > 6000
Et beaucoup de chose encore
Je pense que le problème vient de là
Par exemple les achats ce n’est pas trop lent, la table entêtes contient > 2000 et les détails > 14000
Le nombre de fournisseur < 50
Aussi pour d’autres clients qui ont le même logiciel, et qui font a peu prés 50 % du chiffre d'affaire du client en question, ça fonctionne mieux, mais avec plus de lenteur a la fin de l'année

Merci

Oui effectivement c'est raisonnable... En comparaison j'ai 70.000 lignes de commandes et 800.000 mouvements de stock et ça reste rapide
Avec SQL server il serait probablement possible de garder toutes les années en base, ça simplifie le changement d'année et permet de voir les historiques

Dans mon logiciel j'ai programmé le VBA pour avoir le choix de la base access ou SQL server. C'est un peu plus de travail mais comme ça le client a le choix et pour une petite installation, access est bien plus rapide !

Dernière question, les utilisateurs sont tous connectés en ethernet gigabit ? Sinon cela peut expliquer les lenteurs, il y a énormément d'échanges entre client et serveur avec JET

[adlinformatik]

Avec SQL server il serait probablement possible de garder toutes les années en base, ça simplifie le changement d'année et permet de voir les historiques

Pas de problèmes de ce coté là, le changement d'année est très rapide, l'utilisateur n'a que cliquer sur une liste déroulante, le code supprime toutes les tables liées a la base de l'exercice en cours et lie ceux de l'exercice sélectionné, en plus en général on consulte rarement lest exercices précédents, un peu au début de l'année et puis rien
Pour les situations clients par exemple, un bouton sert à basculer entre l'historique de l'année en cours et celui de l'année précédente et c'est rapide etc.

Dernière question, les utilisateurs sont tous connectés en Ethernet gigabit ? Sinon cela peut expliquer les lenteurs, il y a énormément d'échanges entre client et serveur avec JET

Oui j'ai oublié ce point très important, le Switch est un 10/100 pas en Gigabits, alors que tous les PCs sont bons équipés de disques SSD, et la plupart sont munis de cartes réseaux en Gigabits
Mais pour proposer au client d'investir il faut faire des tests et le convaincre des résultats
Merci pour cette précieuse remarque

[nico84]

Oui j'ai oublié ce point très important, le Switch est un 10/100 pas en Gigabits

Inutile de chercher plus loin dans un 1er temps... Quand la base dépassera les 100Mo avec plus de 10 users il sera toujours possible de passer à sql server !

[loufab]

Bonjour,

Aussi pour d’autres clients qui ont le même logiciel, et qui font a peu prés 50 % du chiffre d'affaire du client en question, ça fonctionne mieux, mais avec plus de lenteur a la fin de l'année

Si avec moins de données ça marche mieux, il serait bon de regarder comment cette appli est conçue.
Vérifier toutes si toutes les requêtes et rowsource sont correctement conçues.

Cependant en multiutilisateur un SGBDR plus adapté est forcément conseillé.

Cordialement,

[adlinformatik]

Bonjour,



Si avec moins de données ça marche mieux, il serait bon de regarder comment cette appli est conçue.
Vérifier toutes si toutes les requêtes et rowsource sont correctement conçues.

Cependant en multiutilisateur un SGBDR plus adapté est forcément conseillé.

Cordialement,

Merci beaucoup