[AC-2007] Plantage avec évènement Change

[JFDAccess]

* Bonjour *


Ci dessous un problème que je ne sais pas documenter correctement de plus je suis incapable de savoir s'il faut le mettre dans ce forum ou IHM, ...

Lors de l'affichage d'un formulaire (assez complexe) avec des Tabs, pas de problème au premier affichage, puis -mais d'une façon aléatoire - sur click sur un autre tab, il arrive assez souvent que j'obtienne des plantages différents (avec ou sans demande de sauvegarde, avec ou sans redémarrage...)
Le passage d'un tab à un autre est traité par un select case dans

Code :

1
2
Private Sub TabBilan_Change()
...

• Une fois ce premier plantage réalisé, en relançant le programme et les mêmes opérations, le plantage devient systématique
• En mettant un Stop sur le traitement du tab_change pour suivre pas à pas le déroulement du processus, le programme ne plante plus !!!

J'ai mis un timer dans le code pour voir si c'était un problème de synchronisation quelque part dans le code => plantage identique

Seul l'insertion d'un stop (qui donne la main à l'éditeur de code) permet de poursuivre le code.

Quelqu'un a-t-il une idée ??? Comment résoudre ce problème ou au moins mieux le documenter ???

Merci
JF Denes

Merci.

[Orion34080]

Pas tout compris dans ton problème de "Tabs" ???
Tu parles de Tabulations ?
et d'un ordre de tabulations ?

Qu'as-tu dans la procedure "Private Sub TabBilan_Change()" qui te fait planter ... si c'est bien cette proc qui plante, bien sûr

Michel

[marot_r]

Vérifie la taille de ta base, si tu es proche des 2 Go il se passe des choses bizares.

Si ce n'est pas cela, essaye une compression de la BD.

Si cela ne donne rien, essaye de créer une base vierge et d'y importer tous les objets. Attention si tu as des menus perso il faut passer par les options pour les importer.

Enfin tu peux essayer le paramètre non documenté de la ligne de commande /decompile.

A+

[JFDAccess]

Merci,
Je ne connaissais pas l'option /decompile, malheureusement sans effet (sinon qu'il me semble que les réponses sont plus rapides)

PS, la base est "petite", 50 Meg.
JF

[Domi2]

Bonjour,

En plus de la décompilation, as-tu compacté ta base ?

As-tu créé une base vierge en y important tes objets ?

Sinon, est-ce que tu utilises des recordsets ? Notamment, est-ce que tu en déclares lorsque tu changes d'onglet ?

Domi2

[Philippe JOCHMANS]

Bonjour

Envoyé par JFDAccess

En mettant un Stop sur le traitement du tab_change pour suivre pas à pas le déroulement du processus, le programme ne plante plus !!!

En général (pas tout le temps) lorsqu'une méthode en pas à pas fonctionne et non en continu, cela dénote un processus qui se s'est pas fini alors que l'on veut en lancer un autre.

Par exemple, création d'une table et tout de suite après on lance une requête sur cette table, ce qui a pour effet de bloquer, car la création de la table n'est pas finie.

Pour éviter ce genre de choses on est amené à utiliser l'instruction DoEvents qui permet de lancer la suite lorsque tout ce que est avant est fini.

Il se peut que ce soit un phénomène similaire, donc peut-être que l'utilisation de cette instructions à des endroits stratégiques pourrait solutionner ton problème.

Philippe

[JFDAccess]

Bonjour,

Merci à Philippe et Domi2

• Pour Domi2 : Oui au 3 questions, (et il y a des recalculs de recordset pour populer les sources de graphs dans le tag du formulaire).
• Pour Philippe, j'avais déjà essayé en mettant un Do Events mais visiblement il était trop court! J'ai refait l'essai avec une boucle beaucoup plus longue, et, Oh miracle ça marche
  
  Mais alors y a-t-il un moyen de trapper la fin des évènements que Acces est entrain de gérer, pour ne pas attendre inutilement et optimiser un peu cette boucle "inutile" en principe ?

Mais encore merci, ça résout mon problème

[Philippe JOCHMANS]

RE

Pour cela il faudrait savoir ou se trouve le blocage dans ton code

[Domi2]

Bonjour,

Les deux pistes suivies semblent intéressantes.

Vérifie bien que tes recordsets soient correctement libérés, parce que ce genre de plantage, c'est assez symptomatique.

Domi2

[JFDAccess]

Bjr,

L'onglet bilan contient un tableau (ListeMvtsImmob) dont la source est effectivement une requête, mais je prenais soin de faire un reset de la source par :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
Private Sub TabBilan_Change()
'*******************
 
Stop
 
    Select Case TabBilan
        Case 0
...
        Case 5
            'Immob
            QuelImmeuble = 21
            QuelleAnnéeImmob = Year(Now())
 
        MsgBox " ici 1"
            ListeMvtsImmob.RowSource = ""
        MsgBox " ici 2"
        'If TempVars("AvecStop") > 0 Then AttendsUnPeu
 
        Case Else
            Stop
    End Select
 
    MsgBox " ici 3"
End Sub

Ce code est le dernier du traitement fait dans a dernière

En cherchant à documenter la séquence des événements, pour cerner le point de blocage, J'ai été confronté à une réaction que j'ai du mal à décrire ! je garanti que j'étais à jeun et non "bourré" :

• J'ai mis un arrêt en début de procédure Tab_BilanChange,
• et un msgbox de ligne en ligne

Dans ce cas (avec Stop) pas de plantage car le code source s'ouvre et on suit bien les Msgbox 1/2/3

Si, on ferme le formulaire ( pour se remettre dans les mêmes conditions), après avoir supprimé le Stop de début de procédure, et on refait la même manip

• Ici 1 s'affiche
• on passe de l'onglet O au 5 sans affichage de Ici 2
• Plantage

=> Manifestement le fait d'activer le code source élimine le problème même en ne le laissant affiché que pendant un temps très court, mais pas l'affichage d'un msgbox seul (même en le laissant longtemps)

Je sens bien que cette documentation est sans doute insuffisante pour comprendre, mais je ne sais pas quoi faire d'autre pour mieux cerner.

Merci,
JF D

[Domi2]

Bonjour,

Ce n'est don pas un recordset qui est est responsable.

En mettant un DoEvents en ligne 17 (avant le deuxième message), ça change quelque chose ?

Domi2

[JFDAccess]

Bonjour,

Je viens d'essayer, mais même cause, même cause, même punition!