VBA: Tester la vitesse de connexion du lecteur réseau

Question

Quelle est la meilleure façon de tester la vitesse de connexion réseau sur le lecteur réseau sur lequel mon projet Excel est stocké?

Beaucoup de mes clients se sont plaints que mon projet excel est trop lent (en dehors du réseau). En effet, certains des bureaux ont des connexions plus lentes que d'autres au lecteur réseau où ils sont stockés (et son backend d'accès). Je pense qu'il serait mieux d'essayer d'écrire une macro qui mesure la vitesse de connexion à l'endroit où la feuille Excel est exécutée, et si elle est en dessous d'un certain seuil, je vais avoir un message d'avertissement disant l'utilisateur doit télécharger une copie localement.

Des recommandations de comment je peux faire cela?

Merci, Dan

Ma seule idée à ce jour est de sortie 10.000 caractères répétés à un nom de fichier aléatoire dans ActiveWorkbook.Path puis supprimez-le. Basé sur le Now() avant et après cette opération, je peux estimer la vitesse de connexion. Cela a beaucoup de problèmes potentiels ... lecteur complet, autorisations d'écriture, équilibre entre l'exécution et la précision.

Answer 1

Essayez d'écrire un nombre fixe de caractères dans le même répertoire que le classeur est stocké (Workbook.Path). Faites-le dans une boucle for, et faites-le répéter de sorte que 10.000 caractères sont écrits (ou n'importe quel nombre que vous choisissez). Faites une déclaration de synchronisation avant et après. Déterminez où une coupure appropriée est en secondes et affichez un message pour toute personne qui a pris plus de temps que votre temps de coupure.

Answer 2

Je suppose que le problème n'est pas avec votre application Excel en soi. Qu'il s'agisse d'un fichier xls ou xla, le fichier est chargé dans la RAM sur l'ordinateur client. Le problème est le gorille d'accès de 800 livres.

Comme vous le savez peut-être, Access n'est pas une base de données client-serveur, même si la MDB peut être installée sur un serveur de fichiers. Lorsque vous exécutez une requête (SQL ou QueryDef) à partir du client, toutes les données requises dans la requête sont transférées au client. Ceci est en contraste avec une vraie base de données client-serveur (pensez SQL Server ou Oracle) où la requête est résolue sur le serveur et seulement les résultats retournés au client.

Quelques suggestions:

1) Enregistrez le temps juste avant et après les exécutions de requête et d'écrire les résultats dans un fichier texte central. Cela sert uniquement à identifier les requêtes les plus lentes. Fixe-lui les pires coupables en premier.

2) À l'aide d'une copie de la MDB, expérimentez l'indexation des tables. Regardez quels champs non uniques sont utilisés dans les clauses where. Réduisez les jointures autant que vous le pouvez.

3) S'il s'agit principalement d'un outil de reporting, pouvez-vous dénormaliser les tables? L'accès souffre gravement des problèmes de performance de profondeur de table.

4) Pouvez-vous mettre les données en cache localement? Si une solution permettait aux utilisateurs de sélectionner les données dont ils avaient besoin (généralement une fraction de l'ensemble) et de les mettre en cache sur leur lecteur C :. Les requêtes suivantes ont été exécutées sur les données locales.

5) Utilisez-vous un classeur partagé? Evitez ceci si possible.

6) Parlez à vos utilisateurs. Découvrez précisément ce qu'ils trouvent lent. Quand. Quelles actions prenaient-ils?

Tous les meilleurs

Answer 3

Vous pouvez utiliser ICMP Echo. Microsoft a du code pour une version VisualBasic http://support.microsoft.com/kb/300197 qui pourrait être adaptée pour VBA.