Discussion :

[Kintin]

Bonjour à tous,

Il y a beaucoup de discussions sur ce sujet mais je n'y trouve aucune réponse (de plus, beaucoup de messages sont obsolètes).
Nous avons une grosse base de données Access qui "plante" de façon assez aléatoire, entre 1 et 20 fois par semaine . (message d'erreur en objet)
Cette base est constituée d'une dizaine de dorsale (en *.accdb). Celles-ci sont sauvegardées et compactées régulièrement.
Chaque utilisateur doit copier la frontale sur son bureau (toujours en accdb).
Certains utilisateurs sont sous office 2016, d'autres 2013 (et quelques rares sont encore en 2010). Les dorsales sont donc toujours en 2010.

Par moment, (l'on ne parvient pas à comprendre pourquoi,) les utilisateurs sont déconnectés et le message d'erreur apparait.
Nous avons checké nos codes vba, les pcs pouvant causer le problème, la qualité de notre réseau et divers conseils trouvés ça et là sur les forums.

J'écris ce message en désespoir de cause en espérant que quelqu'un connaitrait une solution miracle à ce problème.

Notre seule méthode de récupération est actuellement de demander à tous les utilisateurs de se déconnecter (ou de rebooter le serveur), de supprimer le fichier *.laccdb, de vérifier que les clés primaires n'aient pas sauté, de vérifier si des caractères chinois ne se sont pas intercalés (auquel cas, de copier la dernière sauvegarde). Bref, c'est très très lourd comme opération.

Avez-vous déjà rencontré ce problème et quel a été votre diagnostic/solution?

ps: nous ne sommes pas informaticien de formation donc access et le vba sont notre limite d'autodidacte.

[james68]

Bonjour,
Pas simple de répondre à une telle question sans avoir accès au code, a la BDD ou au réseau.
J'ai eu quelques soucis sous A2000 avec des champs MEMO dans mes tables ou je me retrouvais avec des caractères chinois.
Erreur pendant la sauvegarde... rupture réseau... coupure d'alimentation générale.
Au final j'ai refais un conteneur Access vide et j'ai ripé toutes mes tables dans le nouveau container et refais toute la structure relationnelle.
J'ai déplacé la base de données sur une autre disque physique serveur et jusqu’à présent tout est stable.
Une bizarrerie qui persiste a ce jour c'est que le .ldb de la BDD ne se ferme pas automatiquement qd toutes les dorsales sont fermées.
Je ne me suis pas encore penché sur ce problème résiduel car il n’influe pas sur les data ou sur le fonctionnement du soft.
Cordialement.

[User]

Bonsoir,

Vous avez peut-être déjà eu cette réponse, mais si votre base est corrompue, il faudrait peut-être envisager un import complet de tous les objets dans une base vierge avec un compactage.

Cdlt,

[Ric500]

Bonjour,

Une solution peut-être déplacée par rapport à ta problématique, force le serveur de données à rester "en contact" permanent avec la frontale. Pour ce faire, j'ouvre systématiquement dès le lancement de la frontale, un formulaire caché, pointant sur une table qui ne contient qu'un seul enregistrement et un seul champ (tblConnect): cela force un rafraîchissement toutes les 60 ms (par défaut) des données sur le réseau et améliore ainsi les performances des transferts de données via ce réseau en supprimant les latences.

Après, les caractères chinois, çà sent pas bon pour les index: une reconstruction à partir d'une base vierge par importation de tous les objets me paraît aussi une solution à tester.

Bonne journée!

[plnomic]

Bonjour Kintin,

Nous sommes une petite PME dont l'ERP fonctionne sous Access 2016 (portage depuis access 97...)
Nous avons une dizaines d'appli frontales qui communique avec une BDD dorsale sur dossier partagé.

Nous avons exactement les mêmes crash que toi:

Par moment, (l'on ne parvient pas à comprendre pourquoi,) les utilisateurs sont déconnectés et le message d'erreur apparait.

"Format de base de données non reconnue"

Nous avons déjà passé beaucoup de temps à investiguer le problème (dont un expert Access indépendant), en vain
(nous n'avons pas non plus d'expert informatique/access interne)
Le problème est apparu pour (il me semble...) juste après un compactage de la dorsale.

La solution de contournement actuelle est d'utiliser Access en RemoteApp sur un Windows Server: aucun crash dans ce cas (frontale et dorsale sur la même machine physique donc)

As-tu trouvé une solution à ce problème?
Merci d'avance

[Kintin]

Bonjour à tous,
Désolé pour la réponse tardive mais je n'étais plus au travail.

Ric500, Nous allons essayer ta solution (tblConnect) qui semble correspondre à nos attentes. Cela va nous demander plusieurs jours (semaines) le temps de nous réunir et d'en discuter.

User, le compactage est fait de manière régulière car nous manipulons beaucoup de données et les 2 Gigas que permet access se remplissent très vite. L'importation dans des bases vierges a déjà été testée mais le problème persistait. Mais effectivement c'est une des 1ère chose à essayer car le vrai code d'origine d'access n'est pas vérifiable.

james68, nos caractères chinois ne surviennent qu'en de rare plantage, je dirai entre 1 et 5% des cas. Et ceux ci concernent le plus souvent nos clés primaires (date, numerique et texte).
Il est vrai que notre serveur est un peu vieillot, mais il n'est malheureusement pas budgéter de nous le remplacer. Enfin, nous avons également sporadiquement les fichiers ldb qui ne suppriment pas automatiquement à la fermeture mais un simple reboot suffit lorsque le delete ne fonctionne pas.

et enfin plnomic, je ne connais pas la methode ("RemoteApp sur un Windows Server") dont tu parles, et je vais me renseigner à ce sujet, mais si je comprend bien cela n'est pas possible dans notre cas d'avoir la frontale et la dorsale sur la même machine vue qu'une trentaine de frontale peuvent être ouverte simultanément.

La seule solution que nous ayons trouvée est à long terme car nous avons fait appel à un service extérieur qui va développer notre programme dans un autre langage plus souple qu'access (Java/sql/php) et en mettant la dorsale sur un serveur virtuel situé je ne sais où.

En tout cas merci à tous de vous être penché sur cette bouteille à la mer. Mine de rien cela nous fait bien avancer.

EDIT : J'oubliais de préciser, je pense que le problème survient lorsque la dorsale importe une grosse quantité de données et que plusieurs utilisateurs sont en train de bosser sur leurs frontales.
En effet, nos dorsales sont alimentées régulièrement par des importations de *.csv et à ce moment le serveur montre des signes de faiblesse.

ps: je ne mettrai résolu qu'après avoir testé la solution proposé par Ric500 et checké la méthode de plnomic

[plnomic]

En RemoteApp, toutes les frontales tournent sur un seul PC serveur physique.
Chaque utilisateur accède à sa frontale en "Bureau à distance", en ouvrant une session sur le serveur.

J'ai mis ça en place (avec peu de compétences, vraiment pas mon métier) sur un vieux Windows Server 2008 Foundation R2, avec peu de ressources, et ça marche très très bien avec 10 utilisateurs.
'inconvénient est d'être très coûteux si beaucoup d'utilisateurs (licences utilisateurs CAL à payer à Microsoft...)

Nous essayons actuellement cette idée:
https://www.developpez.net/forums/d1...-base-donnees/
https://github.com/MicrosoftDocs/win...ocs/issues/934

A suivre

[claude21]

Bonjour,

On a eu la même chose que vous les index et relations avaient disparu il a fallu les reconstruire (pour les index cela a été aussi l'occasion d'en enlever des superflus).

Mais l'origine du problème venait d'une mise à jour windows.

Je vous invite à regarder ce post
https://www.developpez.net/forums/d1...-base-donnees/
https://github.com/MicrosoftDocs/win...ocs/issues/934

Après avoir appliqué cette solution sur les postes manipulant le plus de données le souci n'est plus revenu (bientôt 3 semaines)

En espérant que cela soit la même chose pour vous.

Edit :

Je n'avais pas lu le message au dessus mais pour je confirme le post au dessus

[chrtophe]

Ne serait il pas possible de passer tout le monde sur la même version d'office ? ça peut peut-être améliorer les choses. Vu la fréquence de plantage, pas grand-chose à perdre à essayer.

Autre piste, l'import CSV, si tu remarques des plantages suite à ça essayes de le faire avec aucun utilisateur connecté, au moins pour voir si ça a une conséquence.

L'idée étant de tenir jusqu'à la fin de développement du produit remplaçant.

[Kintin]

Merci Claude21, et plnomic

J'ai finalement appliqué votre solution (depuis 1h et cela semble être plus stable).
Cependant un nouveau message d'erreur est apparu. Si je n'y trouve pas de solution je ferai un nouveau sujet là dessus mais voici un résumé :
"Impossible d'exécuter cette action pour l'instant". Cela a provoqué une corruption similaire (sauf que le message d'erreur est survenu dès l'ouverture de la frontale)
D'après une courte recherche, cela pourrait venir du fait que le pc soit sous Windows 64bit et qu'Office soit en 32.

pour chrtophe, le changement des versions Office s'effectuent progressivement mais de toute façon je suis vraiment convaincu que le problème se trouve dans la mise à jour 1803 de Windows10. (les liens plus haut sont assez clair à ce propos)

Bonne journée à tous. J'indique le post en résolu jusqu'à preuve du contraire.

[Kintin]

Rebonsoir à tous,

Un petit passage rapide pour signaler que la modification du regedit sur le pc contenant les dorsales n'ont finalement pas résolu le problème.

[claude21]

Bonjour,

Avez vous aussi appliqué les correctifs sur les postes des utilisateurs ?

Cordialement

[Kintin]

Rebonjour,

Effectivement, il fallait attendre que le service ICT effectue la modification sur les différents ordinateurs.
Il n'y a plus de problème. Si je pouvais j'offrirai la tournée ;-)

ps: voici pour info les lignes de regedit à modifier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

[plnomic]

Désolé pour ma réponse tardive, mais oui, il faut appliquer la modif sur tous les PC utilisateurs.

Aucun plantage depuis 1 mois!

[possible924]

J'ai eu le même problème
Si ta solution fonctionne, j'offrirais bien moi aussi un tournée
Vraiment merci
Pierre (possible924)

[Kintin]

la modification du regedit a résolu le soucis mais il faut l'effectuer sur chaque pc qui utilise les frontales.

Bàt,

[james68]

Merci, je vais tester cela demain soir...
++

[cuatan]

alors la Kintin.. bravo , je sais pas pourquoi , mais ces 3 lignes de la registry me sauvent .. ca fait des heures que je galeres avec un bdd qui plante un peu quand elle veut (pourtant pas de frontale ou de dorsales , c'est juste un bdd autonome...) mais toujours ce message "format de base de donnees non reconnues".

depuis la modif ,plus d'erreur... bravo l'artiste et merci