Il y a quelques années, j'ai créé un fichier Excel pour mes collègues qui affiche beaucoup de données provenant d'une source de données ODBC externe. Les données sont partitionnées en lots de tables de données dans différentes feuilles. Le fichier contient également un bouton qui permet à l'utilisateur de mettre à jour les données. Comme l'accès aux données depuis la source externe était très lent, j'ai implémenté une logique de mise en cache qui stockait des parties des résultats, qui étaient peu susceptibles de changer, dans des tables externes sur notre serveur SQL et faisait un peu de magie pour synchroniser les données . Le fichier Excel lui-même accède uniquement au serveur SQL. Chaque table de données utilise un SPROC pour obtenir une partie des données.Synchroniser l'accès aux données
Avance rapide 5 ans. Le fichier Excel a grossi et contient tellement de feuilles et de données que notre Excel (version 2003) a rencontré des problèmes. Mes collègues ont donc divisé le fichier en deux parties.
Le problème est maintenant, que les deux fichiers Excel contiennent la logique pour mettre à jour les données et il peut arriver qu'un utilisateur clique sur le bouton de mise à jour dans le numéro de fichier. 1 alors qu'un autre utilisateur met déjà à jour le numéro de fichier. 2.
C'est le point où la logique de mise à jour devient berserk et produit des ordures.
La mise à jour est requise une seule fois pour les deux fichiers Excel car elle met à jour toutes les données affichées dans les deux fichiers. C'est assez cher et dure de 5 à 15 minutes.
Je pourrais également diviser la mise à jour en deux moitiés, mais cela ne le rendrait pas plus rapide et la mise à jour des deux fichiers prendrait deux fois plus de temps. Ce à quoi je pense, c'est une sorte de mutex: L'utilisateur A clique sur le bouton de mise à jour et l'exécution de la mise à jour commence. L'utilisateur B veut également mettre à jour, mais la logique (VBA/SPROC) détecte qu'une mise à jour est déjà en cours et attend qu'elle se termine.