Crash de base de données

La communauté bonjour,

Nous avons développé au sein de notre boîte un logiciel de gestion de magasins (environ 1000 points de vente) fonctionnant en réseau. Ce logiciel développé sous Access 2013 (une base frontale sur chaque poste et dorsale sur le serveur) fonctionnait très bien jusqu'au mois de Mars. Or depuis quelques temps la base de données Access tend à crasher chez de nombreux utilisateurs (utilisation du Runtime Access 2013 et tests en RT 2016 également). J'ai pensé que les modifications de la structure de la base étaient responsables de cette instabilité mais certains de nos clients qui n'ont pas fait les mises à jour semblent sujets à ces mêmes désagréments. En analysant le problème, il nous paraît fortement probable qu'une mise à jour Windows 10 serait à l'origine du problème. Les clients équipés de Windows 7 ne sont pas impactés.

Le crash n'impacte pas la totalité du parc (environ 8%), ce qui est un seuil relativement important toutefois.

Peut-être avez-vous un retour d'expérience sur ce sujet, ou des pistes à explorer qui me permettrait de satisfaire nos clients.

Merci d'avance
JimboLion

Bonjour JimBoLion,

Question naïve :

Es-tu sûr qu'il n'y a pas moyen de récupérer une erreur dû au contexte ou autre, car comme tu dois le savoir avec le runtime ça plante systématiquement ;)

Cdlt,

Denis bonjour,

Merci de te pencher sur mon problème.
Jusque là je n'avais pas eu spécialement de problèmes avec le RunTime et me dire que des clients qui ne sont pas passés à la dernière MAJ de notre logiciel sont impactés par ce problème me laisse dubitatif quand même. Je suis sûr que l'explication est bien dans une MAJ de Windows 10 puisque quelque soit la version de l'applicatif, aucun impact sur mes clients Windows7. Il y a crash avec le RT j'en suis conscient mais çà restait un problème à la marge quantitativement et en fréquence. Aujourd'hui la base peut crasher 5 fois par jour.

J'avance de mon côté et j'ai peut-être une explication rationnelle avec SMB1 car parallèlement les réseaux et les règles de partage réseau n'ont plus l'air de très bien fonctionner (obligé de passer l'IP sur certains postes pour se connecter sur le serveur).

J'ai mis en place une procédure chez certains clients pour réactiver ce SMB1 (MAJ Mars 2018 à priori) et je tiendrai la communauté au courant.

Amicalement
Jean-Marie

Cher tous,

Visiblement ce correctif ne change rien à la situation. Je creuse encore...

jm

La communauté bonsoir,

Je crois avoir trouvé la solution concernant ces fameux crashs. Le problème est identifié chez Microsoft et touche effectivement la mise à jour Windows 1803 sur les postes de travail Windows 10 Pro.
Les éléments d'analyse portent sur les versions Runtime 2010, 2013 et 2016 dès lors que les accès utilisent le moteur de base de données JET (DAO).

La solution consiste à mettre à jour le registre sur les postes Windows10. Copier ces quelques lignes dans un éditeur et enregistrer dans un fichier de type .reg (exemple SMBCacheFix.reg)

Citation:

---

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

---

Exécuter ce fichier en double cliquant dessus depuis l'explorateur.

Depuis quelques jours que nous avons mis en place cette procédure, plus de corruptions de base décelées.

Le lien ayant permis de résoudre ce problème : https://github.com/MicrosoftDocs/win...ocs/issues/934

Bonne soirée

Jimbolion

Salut Jimbolion,

Merci pour le partage de votre solution :ccool:

Il semble que nous avons le même problème, que depuis nous avons migrer de serveur à sbs 2008 à serveur 2012 R2. access plante en tout temps en affichant ceci (base de donner incohérent)Je me demande si celà a un lien le fait qu'on est migrer de serveur.

J'aurais bien avoir la solution.

Bonjour Jimbolion,
Nous rencontrons le même problème depuis 2 ans sans avoir trouvé la solution pourtant convaincus comme toi que le problème se situait au niveau du système - mais nous ne devons pas être suffisamment calés en Anglais pour trouver le patch.:france:
J'ai appliqué le correctif sur 2 sites impactés, il semble que cette solution fonctionne. :kiss:

Pour Morand01,
Je ne suis pas sûr qu'il s'agisse du même problème car nous avons plusieurs clients utilisant nos applications Access 2010/2013 qui ont procédé à des migrations de leurs serveur 2008->2012->2019 au fil du temps et nous n'avons pas eu de retour d'instabilité comme c'est le cas depuis W10.