Discussion :

[alain31tl]

Bonjour,

Mon application (de type creationComplete) est initialisée par une première requête, pour affichage des données.

//Requete de base 1
<mx:HTTPService id="newRequest" url="...

Bref, trés bien.

Pour supprimer une donnée, j'utilise une autre requête.

//Requete 2 ( Suppression_Id )
<mx:HTTPService id="supListRequest" url="...

Par conséquent et dans ma fonction, j'utilise la méthode suivante :

private function Suppression_Id():void {

//....boîte d'alerte
//...etc

private function listconfirmHandler(event:CloseEvent):void {
if (event.detail == Alert.YES) {

supListRequest.send(); // suppression de l'id de référence

newRequest.send(); // Réinitialisation des données

}

Ce qui me semble dans l'ordre des choses.
Et pourtant, 1 fois sur 3, la donnée supprimée reste affichée alors qu'elle a bien été supprimée de la DB.(Vérifié)
Et si je relance l'application, elle a bien sûr disparue.

Pourrait-on en déduire que :

supListRequest.send(); // suppression de l'id de référence

newRequest.send(); // Réinitialisation des données

s'éxécutent de façon aléatoire, c'est à dire de manière non ordonnée ?

Merci à vous pour vos remarques.
Cdt

[jylaxx]

Les requêtes sont bien envoyées dans l'ordre. Par contre rien ne permet de s'assurer que la seconde ne sera pas exécutée avant la première sur le serveur.
Les requêtes SQL de mise à jour étant souvent plus lente que les requêtes de lecture il n'est pas surprenant que celle-ci soit exécutée alors même que la requête de suppression n'est pas terminée.
Pour se synchroniser il faut donc intervenir soit du côté serveur, soit du côté client.
Côté serveur il faudrait que la requête suplistRequest renvoie le résultat du select après la suppression, ou bien créer une troisième requête supListSelectRequest qui enchaîne les deux opérations.
Côté client il faudrait n'exécuter le selectRequest qu'au moment de la réception de la réponse de la requête supListRequest.

[alain31tl]

....Par contre rien ne permet de s'assurer que la seconde ne sera pas exécutée avant la première sur le serveur....
Les requêtes SQL de mise à jour étant souvent plus lente que les requêtes de lecture il n'est pas surprenant que celle-ci soit exécutée alors même que la
requête de suppression n'est pas terminée......

Effectivement et bien vu, c'est ce que je pressentais, tout du moins un problème du genre.

Pour tester, j'ai forcé le processus de remise à jour en le relancant plusieurs fois, par exemple :

supListRequest.send(); // suppression de l'id de référence

newRequest.send(); // Réinitialisation des données
newRequest.send(); //...
newRequest.send(); //...
newRequest.send(); //...

Celà fonctionne, ce n'est pas plus lent à l'oeil, mais pas trés rationnel à mon goût.

J'avais lu un article se rapprochant dans un certain sens, de ces états de fait.
Le cas de figure est différent mais pourtant interressant

Je vais par conséquent m'orienter vers ta dernière suggestion qui me semble plus approprièe.
Je donnerai suite avant de clouter le thread.



Merci jylaxx pour cette intervention.

[alain31tl]

...Côté client il faudrait n'exécuter le selectRequest qu'au moment de la réception de la réponse de la requête supListRequest....

Ok, corrigé.

J'aurais pu y penser plus tôt mais Flex...je découvre petit à petit.

<mx:HTTPService id="supListRequest" ............. result="resultSuppression(event)">

private function resultSuppression(event:Event):void{
newRequest.send();
}

Merci jylaxx