Discussion :

[james68]

Bonjour à tous,
Depuis quelques temps j'ai ma base de données qui plante très souvent.
je me retrouve avec le message "Format de base de données non reconnu"
Au niveau environnement la base de données est sur un disque dur réseau sur un serveur.
j'ai 6 pc client qui se connectent cette base de données.
le Frontal et la dorsale sont en .mdb et des runtime access 2000 sont installés sur chaque PC.
Les PC sont en win 10 pro avec un office complet 2016 (word excel access etc)
Régulièrement la base de données plante sans aucune raison.
Autre chose en éditant le fichier .ldb sur les poste client j'ai des caractères spéciaux dans ce fichier.
chose que je 'ai pâs sur ma plateforme de développement de l'application.
"?????1††††††††††??n†††††††††††††" présent dans le fichier .ldb
J'ai fait des tests aussi sur un fichier accdb et le résultat est le même dans le fichier de verrouillage Access 2016
Est ce que quelq'un aurait une piste ??
D'avance merci a tous

[User]

Bonsoir,

Peut-être essayer la solution de jimbolion :

https://www.developpez.net/forums/d1...-base-donnees/

Cdlt,

[james68]

j'ai tenté la solution proposé..
mais cela ne fonctionne pas...
le fichier .ldb réagit toujours bizarrement..
apres une reparation et compactage ca fonctionne a nouveau jusqu'au prochain plantage...

[james68]

Un début de piste....
https://www.ginjfo.com/actualites/lo...-2019-20190220
Affaire a suivre...

[User]

Un début de piste....
https://www.ginjfo.com/actualites/lo...-2019-20190220
Affaire a suivre...

Complexe..

[micniv]

Les PC sont en win 10 pro avec un office complet 2016 (word excel access etc)

dans ce cas quel est l'intérêt de rester en runtime 2000 ?

[james68]

car l'appli est en .mdb développé sous access 2000 et non certifié sous 2016.
De plus il y a pas mal de menu et perso je déteste le ruban office.

[micniv]

autre suggestion pour ta problématique :
as-tu essayé de lancé ton appli avec l'option /DECOMPILE (à lancer aussi sur la dorsale), ça ne peut faire que du bien !
L'option /DECOMPILE est bien présentée sur la page de Loufab.

CDLT

[Simplifi]

Bonjour à tous,
j'observe depuis quelques temps le même problème sur un ensemble de 8-10 postes utilisateurs et un serveur. Le problème nous a semblé apparaître à la suite d'une mise à jour de Windows, pendant 2 mois il nous a beaucoup posé question et maintenant, il a l'air de diminuer sans que nous n'ayons fait autre chose que des "compacter et réparer"
A noter: une session ouverte peut continuer pendant pas mal de temps à bien fonctionner alors même que le problème apparaît. Mais une fermeture-réouverture provoque immédiatement l'affichage du message ci-dessus
Par contre, je n'ai jamais bien compris pourquoi chez certains de mes clients, je dois regarder le ldb ou laccdb avec le Notepad, d'autres avec Internet explorer, et sur celui ou je tape, avec Notepad++ !?!?
Dès que je revoie mon client, j'essaie et je vous tiens au courant

[james68]

oui ca serait sympa...
++

[james68]

autre suggestion pour ta problématique :
as-tu essayé de lancé ton appli avec l'option /DECOMPILE (à lancer aussi sur la dorsale), ça ne peut faire que du bien !
L'option /DECOMPILE est bien présentée sur la page de Loufab.

CDLT

je ne pense pas que cela vienne de là.
Dixit LOUFAB --> DECOMPIL : Cette option permet dans certains cas de pouvoir réparer des parties de code endommagées.
A ce jour je fais tourner ce frontal et cette dorsale dans un environnement Win7 PRo et cela fonctionne parfaitement.
A mon sens le problème vient essentiellement de la MAJ de Win10Pro de février 2019.
En tout cas merci de te pencher sur mon problème..
Amicalement James

[flogfr]

Bonjour à tous,

Ceci est mon premier message sur ce forum, je suis développeur sous access depuis 20 ans.
J'ai également rencontré ce type de problème chez un client actuel qui utilise mon application avec 30 postes en réseau.
BD utilisateur installée dans un dossier local et reliée par un lecteur réseau commun à tous les postes à une BD serveur qui ne contient que les tables.
Beaucoup de plantages mettant la bd serveur en sécurité et à réparer sont dus à des coupures réseaux intempestives, soit un pc portable connecté au réseau via un wifi instable soit par un pc portable mis en veille avec le logiciel ouvert.
La seule solution fiable trouvée jusqu'à présent est d'identifier la carte réseau du PC, l'archiver en WIFI ou ETHERNET et bloquer les ouvertures du logiciel si la connexion est faite via le wifi.
Parallèlement à cela, j'ai mis un compteur fermant automatiquement le logiciel si aucune d'activité détectée (mouvement de souris)
Cela fonctionne correctement sauf lorsqu'un utilisateur débranche le câble éthernet avec l'appli ouverte.
Je cherche donc actuellement une solution pour détecter la fermeture du capot d'un pc portable afin de fermer l'application juste avant la coupure réseau due à la mise en veille.
En espérant avoir aidé certains d'entre vous autant que ce forum a pu m'aider jusqu'à présent.

[james68]

Perso apres MAJ Win10Pro manuelle, tout est rentré dans l'ordre