Plantages aléatoires en exécution et en dev

[lbrun79]

Bonjour,

J'ai une appli qui tourne depuis des années sans pépins.

Depuis plusieures semaines (suite à une grosse montée de version), mes utilisateurs se plaignent de plantages réguliers lorsqu'ils effectuent certains actes de gestion : ils se font sortir brutalement d'access et cela provoque des déphasages entre mes tables ce qui m'oblige à corriger régulièrement..

Je n'arrive pas franchement à reproduire les cas .. parfois j'y arrive exceptionnement mais cela semble complètement aléatoire... j'ai mis en place un trace coté Utilisateur pour bien voir ce qui produit le problème.. j'ai refait les cas, rien ne s'est produit chez moi..

J'ai, dans un premier temps, pensé à un ou plusieurs formulaires vérolés .. j'ai donc compacté la base client et le seveur puis j'ai importé les formulaires en
question.

Comme rien n'y faisait j'ai tout réimporté (client et serveur).

Comme le problème persistait j'ai tenté de redévelopper le formulaire qui plantait de a à z en le concevant différemment .. cela se produisait surtout sur un formulaire que j'appellelais sous forme de boite de dialogue et qui, en fait, fermait la fenêtre principale de temps en temps alors que lui restait ouvert : j'ai donc fini par convertir (ce week-end) ce formulaire boite de dialogue en formulaire principal .. j'attend le verdict utilisateur dans les jours qui viennent..

Je ne suis pas trop certain du résultat, puisqu'en développement lorsque j'enregistrais mes modifications dans mon nouveau formulaire, cela plantais régulièrement en me jettant carrément d'Access cette fois .... est-ce le même problème ??

Dans l'utilisation des autres formualires cela semble se passer correctement...

A quoi cela peut-il être du ? problèmes d'instabilités liés à de nouvelles blibliothèques référencées peut-être ... j'en ai rajouté dans ma nouvelle version pour gérer les treeviews et filedialog .. problème de base de données .. j'ai ajouté des index pour optimiser.. autres ?? fichier mdb trop volumineux .. mon mdb client fait 30 MO et ma base serveur 90MO..

Merci de vos réponses et vos pistes .. je sèche complètement et mes Utilisateurs commençent à raler..


Laurent

[=JBO=]

Bonjour,

Dans une telle situation merci de penser à nous indiquer ton environnement de développement et d'exploitation:

Quel système d'exploitation + service pack ?
Quelle version d'Office ?
Architecture de l'application (apparemment tout MDB en dorsal-frontal ?)

Franchement, ça me rappelle de mauvais souvenirs, particulièrement liés à des problèmes de référence.
Et le plantage d'Access devenu instable lorqu'on modifie certains formulaires, c'est du déjà vu.

Peux-tu expliquer les modifications apportées à ton application, la <<grosse montée de version>> ?

As-tu aussi essayé la décompilation ?
A mon avis, c'est une mesure complémentaire aux autres actions de compactage et d'importation.

En ce qui concerne l'ajout d'index, il faut savoir que les requêtes Access sont pré-optimisées quand elles sont enregistrées.
Donc, les nouveaux index ne seront pas utilisés par les requêtes Access, à moins de les ouvrir en mode création, de les "exécuter" et de les enregistrer à nouveau.

Les formulaires et états peuvent aussi être basés sur des requêtes Access "internes". Pour les optimiser (suite à l'ajout d'index), il est judicieux d'ouvrir le formulaire/état en mode création, d'ouvrir la source de données pour afficher la grille QBE et d'exécuter la requête pour afficher la grillle de données.

Ensuite, il faut être certain que ton fichier MDB dorsal de développement et le fichier MDB dorsal d'exploitation ont bien la même structure, en particulier les mêmes index.

Pour les requêtes SQL construites dynamiquement et exécutées à la volée, les nouveaux index seront bien pris en compte.

Donne nous de tes nouvelles et bon courage.
_

[3ci-Toulouse]

SUr ACCESS 97, chez des clients, mais aussi sur ACCESS 2003, j'ai rencontré le même problème.
Sur un ou plusieurs formulaires il semble qu'un problème face planter ACCESS.
Il est impossible de récupérer le formulaire, même en copiant la base.

Sytème : Chez les clients W2K PRO avec un serveur 2003
Chez moi, directement sur le serveur 2003 SR2

??????
Je ne trouve rien, pour le moment chez CROSOFT

A+

[lbrun79]

Bosnoir

Merci pour vos réponses.. je vois que je ne suis pas seul avec mon problème..

Ma config tout d'abord.. J'utilise un bon viel ACCESS 2002 en version professionnelle qui tourne sous XP SP2. J'ai reproduit les problèmes sur d'autres postes eux aussi sous XP .. donc je ne pense pas à problème de config d'autant que cela marchait correctement avant ma montée de version. J'ai par acquis de conscience désinstallé et réinstallé complètement Office pour être sur.

Concernant cette évolution, elle a eu des impacts partout.. j'avais des problèmes de performance alors j'ai mis en place de nouveaux index, j'ai éclaté une grosse table facture en deux deux tables,modifié certaines tables, j'ai mis en place une historisation des données avec visualisation des données historisées avec des Treeviews (nécessité de rajouter MSCOMCTL.OCX en référence).. j'ai crée un bonne trentaine de formulaire et autant de requêtes et fonctions VBA.. J'ai aussi ajouté aussi une nouvelle Référence à "Microsoft Office 10 object library" pour gérer les Filedialog, etc.. Les cause de mon problèmes sont donc potentiellement multiples ..

Les formulaires qui posent problème existaient avant cette modification et fonctionnaient correctement. Je les ai retouché pour cette évolution mais de façon très superficielle..

En fait ce qui est étonnant c'est qu'en recréant de toute pièce de nouveaux formulaires avec à peu près les même champs, j'ai les mêmes problèmes de plantages qu'avec les autres formulaires..lorsque j'enregistre plusieures fois consécutivement ce formulaire, cela plante et me sort d'access.. pourtant ce formulaire ne comporte que quelques champs ..

Qu'est ce que la décompilation ?

Pour les requetes en dev et en prod, j'effectue mes tests avec une copie de la base de prod donc il ne peut pas y avoir de décalages d'index.. je vais par acquis de conscience quand même ouvrir, exécuter et ré enregistrer toutes mes requêtes sélection et toutes les requêtes embarquées dans mes formulaires : au moins mes nouveaux index seont pris en compte..

Autre piste : Dans ma nouvelle version j'ai mis en place un archivage des données : je stocke mes données archivées dans une autre base que j'appellle Archive (j'ai donc deux dorsales), ce qui fait que pour un mdb client donné j'ai des liaisons avec deux bases de données sous-jacentes .. cela peut-il poser problème sachant que sur les postes ou cela déconne les deux bases sont en ligne.

Merci de vos réponses..

Laurent

[3ci-Toulouse]

Après avoir lu quelques infos sur le sujet, il semble qu'une mise à niveau de SP puisse être à l'origine de ce problème.

En message d'erreur, il semble que la DLL en cause soit la NTDLL.dll.
version : 5.0.2195.6685 sur le poste de mon client
version : 5.2.3790.3959 sur mon poste de test
???????

A force de tester, j'ai, sans certitudes, des suspicions sur les controls de types combobox.

[jacou]

Envoyé par lbrun79

Qu'est ce que la décompilation ?

Voici la commande pour décompiler, outil et commande 100% indispensable pour les développeurs en Access:

Code :

1
2
 
"C:\%PATHACCESS%\MSACCESS.EXE" D:\MonRepertoir\MonFichierAccess.mdb /decompile

Remplace %PATHACCESS% par ton chemin installation exécutable Access.

Au démarrage il faut appuyer sur la touche [Shift] pour ne pas lancer des macros AutoExec et companie.

Tiens-nous au courant de ton évolution STP.

[lbrun79]

Bonsoir,

Merci pour la procédure de décompilation.

Concernant les DLL : je suis en 5.1.2600.2180.
Laquelle est sensée être la bonne (la plus ancienne) ? puis-je les interchanger sans risque de rendre instable mon windows pour vérifier si cela marche mieux ?

Concernant les zones de listes, effectivement mon formulaire qui pête en comporte 4 dont 3 avec des données sous-jacentes assez volumineuses.. je vais avoir du mal à m'en passer .. il va falloir que je repense à nouveau ce form..

Merci pour vos réponses ..

Laurent