J’ai un souci avec des vieux fichiers Excel non XML, créés avec un Excel 2003. Lors de leur ouverture ils semblent s’auto-sauver automatique.
Ils ont le même comportement qu’on les ouvre avec Excel 2003 ou 2016, et ça ne le fait pas avec les fichiers XLSX.
Sur ma machine (Win 10 - Excel 2016), dans l’explorer le comportement est encore plus étrange parce que le fichier s’enregistre en mettant à jour le champ “modifié le” à la date de l’ouverture, mais ça ne reste cette date là qu’un instant, et ensuite ça revient à la date de la dernière vraie sauvegarde.
Je pose la question pas seulement pour la science, mais parce que ce sont des fichiers partagés sur une Dropbox. Du coup si on ouvre le fichier déjà ouvert par un autre utilisateur, à cause de cette sauvegarde auto, Dropbox considère que le fichier a été mis à jour et donc qu’il y a un conflit de version. C’est d’ailleurs la flêche de mise à jour Dropbox qui m’a permis de cerner le problème.
Alors je sais que les fichiers XLS ça remonte à 10 ans, d’où le titre, mais si quelqu’un a dans ses souvenirs déjà vu ça, et a une piste pour résoudre le problème… Sachant que la solution simple est sans doute de passer à un Excel moderne qui gère les XLSX, mais j’ai pas la main sur ce choix là…
Pour info, je me suis assuré que ces fichiers ne contiennent pas de macro.
Pour info bis : si on force l’ouverture en lecture seule (c’est une option de la boite de dialogue d’ouverture de fichiers dans Excel), le problème ne se produit pas.
Tu peux pas régénérer le fichier (copie-colle du contenu dans un nouveau fichier) ? Tu peux enregistrer en .xls même dans 2016. Au moins déjà pour tester si ça fais pareil.
Mais il me semble que l’autosave dépend de Excel, je veux dire l’applicatif, dans Outils/Options/Enregistrement et pas du fichier en lui-même.
Et sinon, comme pour Access, la gestion du partage et des données en cours doit très certainement se gérer aussi par un fichier temporaire. En gros dans le cas d’un partage ce fichier annexe sert de fichier lock.
Pour ce qui est de la màj des champs date, pour moi il me semble que ça vient de l’OS, en effet je me souviens avoir rencontré cela pour des fichiers n’ayant rien à voir avec Office.
Liens excel 2007, qui donnent quand même des pistes (à partir de ce dont je me souviens)
edit: en fait il faudrait un comparateur hexadécimal pour voir dans le fichier s’il y a vraiment un octet signifiant l’autosave, en utilisant ta méthode “normale” et ta méthode avec lecture-seule, et en comparant les 2 fichiers.
Alors j’avance un peu : ça semble bien être lié à la gestion des données en cours comme pour Access: si je crée avec Excel 2016 un classeur, quand je le sauve en .xlsx il crée un fichier caché avec un nom similaire, qui est détruit à la fermeture. A chaque ouverture le fichier caché est recréé, et il n’y a pas de mise à jour furtive du fichier principal.
Pour le même classeur, sauvé en .xls, lors de l’ouverture j’ai à nouveau le comportement de mise à jour, et il n’y a pas de création de fichier caché.
Donc je le mets en résolu: grâce à vous j’ai compris ce qu’il se passe (merci ), et aussi que c’est inéluctable (même si je ne comprends pas trop ce que le format en lui-même vient faire là, je suppose qu’Excel pourrait tout à fait travailler sur une copie temporaire de son fichier .xls et ne mettre à jour le fichier principal qu’en cas de sauvegarde…).
Edit : d’ailleurs il faut que je teste comment ça se passe quand on ouvre un même fichier xlsx depuis 2 machines différentes. Logiquement il devrait créer 2 fichiers cachés, mais quels sont leurs noms ? Je me demande s’il est capable de faire ça sans s’emmêler.
Sur Access, comme le client ne voulait pas avoir une vraie base de données partagée, j’avais créé tout un processus de pseudo-transactions : c’est-à-dire que je vérifiais en VBA que les données sauvegardées l’étaient vraiment. Il y a un moment où je me suis barré de chez ce client tellement c’était ridicule: pour ne pas dépendre des services centraux informatiques, ils avaient trouvé cette ruse pour le faire sur un budget bureautique alors que ce n’était pas l’épicier du coin.
Sur un tableur les résolutions de conflit de partage sont un peu plus simples qu’une base de données, mais comme il n’y a pas d’arbitres, ce n’est jamais fiable à 100%, il peut y avoir des soucis. De ce point de vue c’est le jour et la nuit avec les vraies tableurs partagées en ligne récents (partages bien meilleures, mais fonctionnalités quand même plus limitées mais plus pour longtemps).
Tu mets quoi dans les tableurs partagés modernes ?
Edit pour précisions : ça me ferait rager de devoir ré-apprendre à faire autrement tout ce que j’ai pu faire avec VBA qui me simplifie grandement la vie (c’est rien de magique non plus, mais vu que je fais ça sur mon temps libre en solo, c’est une sacrée masse de temps investi). Mais si les logiciels qui permettent de travailler de façon partagée l’imposent, why not.
Par ailleurs est-ce que l’utilisation du cloud de Microsoft, plutôt que l’enregistrement sur un dossier partagé du réseau ou une Dropbox, est utile/nécessaire si je veux travailler de façon partagée avec Office ?
Je parlais de Google sheets ou d’alternatives libres comme Framacalc. En fait ils sont largement plus puissants en terme de partage et travail collaboratifs, mais pour ce qui est des fonctionnalités d’enrichissement des feuilles de calculs ils restent plus limités, et les scripts ne sont pas dans le même langage.
Je l’ignore, puisque je n’ai pas utilisé Office depuis un certain temps, mais ça serait dans la logique. Après une recherche rapide sur internet, il semble qu’effectivement avec le cloud microsoft on a un vrai partage, tout en gardant la puissance d’Excel.
Si le partage n’est pas fiable, tu le sauras très vite, car tu auras les mêmes symptômes qu’en partage à l’ancienne. Or tel que c’est expliqué il semble que ça soit un vrai partage avec un serveur.