Login mot de passe
Plantage presque aléatoire [forum - SQLManagerX]

Parcourir ce sujet :   1 Utilisateur(s) anonymes



(1) 2 »


Plantage presque aléatoire
apprenti-animateur
Inscrit:
2006/10/25 22:34
Messages: 66
Hors Ligne
Bonjour,

J'ai un problème dont je ne sais me dépatouiller !
Dans une fenêtre, j'ai un Zone Répétée qui liste des contacts. A côté, j’ai un détail du contact qui s’affiche lorsque l’on clic sur une ligne de la ZR.
L’affichage des détails est réalisée avec une requête complexe (beaucoup de jointures) et donc j’utilise :mySQLExec()

Si l’utilisateur appuie de nombreuses fois sur la touche [bas] pour passer de contact en contact et qu’il le fait trop vite ; j’ai un beau plantage !
Comme j’utilise ce même fonctionnement dans beaucoup de fenêtre de mon projet, j’ai le problème presque partout !

J’ai un autre problème dont la cause est probablement la même que le problème précédent :
J’ai un tableau de bord avec des tuiles qui là aussi nécessitent des requêtes complexes et donc :mySQLExec()
Si l’utilisateur n’attend pas la fin de l’affichage des tuiles pour ouvrir des fenêtres, cela provoque une erreur.

Dans les 2 cas, le message est le même :
Erreur à la ligne 133 du traitement Méthode mySQLExec.
La dimension 1 du tableau possède 1 élément(s) et vous tentez d'accéder à l'élément 10.

Avez-vous une idée ?

Posté le : 2018/9/6 13:29
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
SQLManagerX Team
Inscrit:
2004/7/1 12:49
De Grenoble (38)
Messages: 2142
Hors Ligne
bonjour,

ton chargement de la fiche est sur quel traitement de la ZR
je pense que le probleme est sur le fait que windev permet de passer sur la suivante ligne de la ZR alors que le traitement n'est pas terminé

tout depend du'ou se situe le code (dans quel code de la ZR)

tu est donc en mdi sinon ce ne serait pas possible

Posté le : 2018/9/6 14:51
_________________
----------
Firetox
8 rue Georges Méliès
38130 ECHIROLLES
..............................
http://emidev.fr
http://www.teecod.fr/web/Informatique/accueil
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
apprenti-animateur
Inscrit:
2006/10/25 22:34
Messages: 66
Hors Ligne
Oui, je suis en MDI.
Le code est sur le traitement "Sélection" d'une ligne.
Effectivement, windev permet de passer sur la suivante ligne de la ZR alors que le traitement n'est pas terminé.

Du coup, comment puis-je m'en prémunir ?

Posté le : 2018/9/6 15:00
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
SQLManagerX Team
Inscrit:
2004/7/1 12:49
De Grenoble (38)
Messages: 2142
Hors Ligne
bonjour,

oui le probleme est la : en fait il faut savoir a l'entree de la procedure si tu est toujours sur le meme id de la ZR et pouvoir arreter la procedure en cours d'execution

une solution est de lancer un thread ExecutePrincipal (identique a l'appel d'une procedure)

mais en premiere ligne de ta procedure tu fait

si ThreadArrête
(threadPrincipal,1alors
   
// code de chargement du detail car le thread s'est arrete
sinon
   
// le thread n'a pas pu etre areter alors il faut patiente
   // et peut etre relancer l'affichage a un moment
fin


c'est la seule façon que j'ai trouver de couper ou arreter un traitement en cours de windev en mdi

Posté le : 2018/9/6 15:15
_________________
----------
Firetox
8 rue Georges Méliès
38130 ECHIROLLES
..............................
http://emidev.fr
http://www.teecod.fr/web/Informatique/accueil
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
apprenti-animateur
Inscrit:
2006/10/25 22:34
Messages: 66
Hors Ligne
Alors là, je ne sais pas (encore) faire !
Peux-tu m'aider un peu plus ?

Merci

Posté le : 2018/9/7 19:16
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
SQLManagerX Team
Inscrit:
2004/7/1 12:49
De Grenoble (38)
Messages: 2142
Hors Ligne
bonjour,

alors comment dire :
pour pouvoir interrompre un traitement dans le cas de mdi ou autre chargement différé il faut passr par les thread

chose a savoir tu ne peut pas appeler dans un thread des lement d'une fenetre

pour ma part j'utilise un thread qui charge les element en memoire et apres je demande a un traitement de remplir les infos dans la fenetre

pour ton code cela serait un peut comme cela (je le fait en fait sur une application qui doit recevoir des notification : le seule moyen pour ne pas bloquer l'appli et de la faire en arriere plan

le thread fait ta requete et une procedure prend le resultat et charge les champs
ce qui permet d'arreter le thread quand tu veux (clic sur un autre elment de la ZR)

je vais essayer de te faire un code qui fait ca d'ici demain pour te montrer : mais c'est la seule solution que je connaisse car il faut pouvoir arreter le traitement et tu peux arreter un thread mais pas une procedure

voila : comme c'est un peu chaud je vais te faire un exemple

Posté le : 2018/9/7 19:58
_________________
----------
Firetox
8 rue Georges Méliès
38130 ECHIROLLES
..............................
http://emidev.fr
http://www.teecod.fr/web/Informatique/accueil
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
apprenti-animateur
Inscrit:
2006/10/25 22:34
Messages: 66
Hors Ligne
C'est super sympa de ta part car là je sèche !
J'attends ton exemple...

Posté le : 2018/9/7 20:15
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
SQLManagerX Team
Inscrit:
2004/7/1 12:49
De Grenoble (38)
Messages: 2142
Hors Ligne
bonjour,

bon voila le mecanisme qui va permttre de controler les tratiement et ne pas se trouver dans le meme traitement simutlanement

une procedure globla

PROCEDURE PG_ChergementEnCours
()
//-------------------------------------------------
// procedure lancer dans un thread secondaire 
// qui permet de savoir qu'on est dans un trateiment
//-------------------------------------------------
indice est un entier
BOUCLE
   
// mettre un code ici pour eviter le warning
   
si indice >=1000 alors sortir
FIN
//------------------------------------------------


ensuite suivant le cas que tu veux c'est assez simple
cas ou tu ne veux pas que le code de cahrgement d'une table ou ZR se lance simultanement (je l'utilise dans une messagerie instannée) : chargement de la ZR

//--------------------------------------------
// on utilise le thread pour attendre que le chargement soit disponible
//--------------------------------------------
TANTQUE ThreadEtat("ChargementTableMess") <> Inexistant _ET_ ThreadEtat("ChargementTableMess")<>-1
    Multitâche
(-1)
FIN
//----------------------------------------
// le thread est dispo donc on fait le chargement
//----------------------------------------
ThreadExécute("ChargementTableMess",threadNormal,PG_ChergementEnCours)
/----------------------------------------

TRATIEMENT DU CHARGEMENT COMME D'HABITUDE

//---------------------------------------------------------
// cahrgement terminé on arrete le thread
//---------------------------------------------------------
ThreadArrête("ChargementTableMess")
//----------------------------------------------------------


ou alors dans un clc de table ou ZR pour eviter que le clic suivant viennent se melanger
dans affichage d'une ligne ou ZR par exemple


//--------------------------------------------
// on utilise le thread pour attendre que le chargement soit disponible
//--------------------------------------------
TANTQUE ThreadEtat("ChargementTableMess") <> Inexistant _ET_ ThreadEtat("ChargementTableMess")<>-1
    Multitâche
(-1)
FIN
//----------------------------------------
// le thread est dispo donc on fait le chargement
//----------------------------------------
ThreadExécute("ChargementTableMess",threadNormal,PG_ChergementEnCours)
/----------------------------------------

TRAITEMENT AFFICHAGE DE LA LIGNE

//---------------------------------------------------------
// cahrgement terminé on arrete le thread
//---------------------------------------------------------
ThreadArrête("ChargementTableMess")
//----------------------------------------------------------


voila on pourrait le faire avec des variable globale mais avec les thread tu peux le faire, et avantage tu peux nommer ton thread comme tu veux (dans threadExecute) donc tu pourrais en avoir un peu partout

je le fait par exemple dans une procedure _executeRequeteSQL qui renvoie une source de données et donc ce mecanisme m'assure que je ne fait pas de mySQLExec simultanné qui font planté la dll

voila en esperant que cela soit clair
j'ai pensé a ca car c'est un code pour une messagerie je rempli la table des message en arriere plan mais faut pas que le user clique sur affichage d'un element de la table alors que je suis dans la requete sql donc j'utilise le premier cas

voila

Posté le : 2018/9/8 10:37
_________________
----------
Firetox
8 rue Georges Méliès
38130 ECHIROLLES
..............................
http://emidev.fr
http://www.teecod.fr/web/Informatique/accueil
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
SQLManagerX Team
Inscrit:
2004/7/1 12:49
De Grenoble (38)
Messages: 2142
Hors Ligne
complement

donc soit on attend et on poursuit le traitement apres qu'il soit dispo

//--------------------------------------------
// on utilise le thread pour attendre que le chargement soit disponible
//--------------------------------------------
TANTQUE ThreadEtat("ChargementTableMess") <> Inexistant _ET_ ThreadEtat("ChargementTableMess")<>-1
    Multitâche
(-1)
FIN


soit on decide de ne pas faire le traitement

//--------------------------------------------
// on utilise le thread pour attendre que le chargement soit disponible
//--------------------------------------------
SI ThreadEtat("ChargementTableMess") <> Inexistant _ET_ ThreadEtat("ChargementTableMess")<>-1 ALORS RETOUR


voila

Posté le : 2018/9/8 10:47
_________________
----------
Firetox
8 rue Georges Méliès
38130 ECHIROLLES
..............................
http://emidev.fr
http://www.teecod.fr/web/Informatique/accueil
Transférer la contribution vers d'autres applications Transférer


Re: Plantage presque aléatoire
Nouveau
Inscrit:
2012/9/19 20:33
De Abidjan Côte d'Ivoire
Messages: 2
Hors Ligne
Merci à Firetox pour la solution des threads mais il faut que l’environnement ainsi que la structure des scripts respecte bien leur usage sinon vous allez toujours planter.

1- Peux importe la complexité de votre requête SQL il faut quelle soit optimisée pour un bon affichage.

Si par exemple vous demander dans une requête à afficher 20 millions d’habitants dans l’ensemble (ALL) soit vous risquez de planter pour toujours jusqu’à redémarrage peut importe si vous utiliser les threads car il y a des éléments qui rentre en ligne de compte:

- La puissance du processeur
- La puissance du débit de réseau si vous êtes en local ou en accès distant
- Le volume d'information à afficher

NB : il va falloir que vous gérer les transactions au sein de votre script afin de passer la main au threads au moment opportun

Seul la gestion des transactions peut contrôler de façon efficace les traitements d'une requête SQL car c'est elle qui peut confirmer la fin d'un traitement.

Posté le : 2018/9/20 16:37
_________________
"Ce qui ce conçoit bien s’énonce clairement et les mots pour le dire viennent aisément".
Transférer la contribution vers d'autres applications Transférer



 Haut   Précédent   Suivant
(1) 2 »




[Recherche avancée]