Discussion :

[LeonCosnyd]

Bonjour,

Je dois faire communiquer un terminal Windows connecté en WIFI à une base HFSQL C/S sur un serveur se trouvant sur le réseau local (pas d'internet).

Étant donnée que le terminal est connecté en wifi (risque de coupure réseau, déconnexions intempestives,etc...) j'ai choisi de créer des fichiers locaux sur le terminal en HFSQL Classic. Depuis l'application j'utilise ces fichiers locaux (donc pas de soucis de lenteur ou de déconnexion).

Pour alimenter ces fichiers locaux j'ai mis en place un système travaillant en arrière-plan (thread).
Par exemple à l'ouverture d'une fiche CLIENT :
1. L'application affiche les données du fichier local (Classic)
2. Je lance une procédure locale ayant pour automatisme : Thread, Executée 1 fois immédiatement au moment de l'appel, Sans utilisation de HFSQL.
Cette procédure ouvre une connexion au serveur HFSQL C/S, execute une requete SQL des informations du CLIENT, met à jour le fichier local.

Voici un exemple de code, procédure syncDonneesClient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
SI HEtatServeur("192.168.1.99:4900") <> hDémarré ALORS RENVOYER(Faux)
 
oConnexionHFSQL	est une Connexion
oConnexionHFSQL	..Utilisateur 		= "MonIdentifiant"
oConnexionHFSQL	..MotDePasse 		= "MonMotDePasse"
oConnexionHFSQL	..Serveur			= "192.168.1.99:4900"
oConnexionHFSQL	..BaseDeDonnées 	= "MaBaseDeDonnees"
oConnexionHFSQL	..Provider  		= hAccèsHFClientServeur
oConnexionHFSQL	..Accès   			= hOLectureEcriture
oConnexionHFSQL	..OptionsCurseur 	= hCurseurClient
oConnexionHFSQL	..Cryptage 			= hCryptageRC5_16
 
SI HChangeConnexion("CLIENT_CS",oConnexionHFSQL) ALORS
	SI HOuvreConnexion(oConnexionHFSQL) ALORS
		HTransactionDébut(oConnexionHFSQL)
 
		QUAND EXCEPTION DANS		
 
			sdResultat est une Source de Données
			SI HExécuteRequêteSQL(sdResultat,hRequêteInterruptible,"SELECT * FROM CLIENT_CS WHERE ..... ") ALORS
				POUR TOUT sdResultat
					HLitRecherche(CLIENT_LOCAL,IDCLIENT,sdResultat.IDCLIENT)
					SI HTrouve(CLIENT_LOCAL) ALORS
						HCopieEnreg(CLIENT_LOCAL,sdResultat,hCopieIdAuto)
						HModifie(CLIENT_LOCAL)				
					SINON
						HCopieEnreg(CLIENT_LOCAL,sdResultat,hCopieIdAuto)	
						HAjoute(CLIENT_LOCAL,hForceIdAuto)			
					FIN
				FIN
			FIN
 
			HTransactionFin(oConnexionHFSQL) 
			HFermeConnexion(oConnexionHFSQL)
		FAIRE
			HTransactionAnnule(oConnexionHFSQL)
			HFermeConnexion(oConnexionHFSQL)
		FIN
	SINON
		RENVOYER(Faux)
	FIN
SINON 
	RENVOYER(Faux)
FIN

Cela fonctionne plutôt bien.

Je rencontre cependant un problème lorsque l'utilisateur veut quitter la fiche CLIENT si la synchronisation n'est pas terminée... J'ai un bouton "Quitter" qui ne fait que ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
FinAutomatismeProcédure(syncDonneesClient)
ferme()

La fenêtre passe alors en mode "je ne répond plus", couleur blanchâtre et ne se ferme pas. Jusqu'à (j'imagine) la fin de la synchronisation....
Savez-vous si le FinAutomastismeProcédure() demande l'arrêt immédiat du traitement ou termine t-il la boucle en cours et s’arrête après ?

En parcourant la documentation PcSoft j'ai vu la fonction ThreadArrete (en travaillant manuellement les threads) mais il est déconseillé pour différentes raisons.

Avez-vous déjà été confronté au problème ? Et si oui quelles solutions avez-vous trouvez pour stopper le traitement le plus rapidement possible ?

Merci d'avance.

[frenchsting]

En mettant un multitache(-1) ?

[DelphiManiac]

Il me semble que ton premier problème est que le code de ton thread est dans la fenêtre et que tu essayes de fermer celle ci sans savoir si le code est effectivement fini; d'autre part au vu de ton code, tu n'a pas moyen de l’arrêter proprement tant qu'il n'est pas effectivement fini. Si tu tentes de le stopper n'importe quand, ta connexion risque de rester ouverte et/ou la transaction pas finalisée.

Conseil :
- Place le code de ton thread dans une collection de procédures
- Ne cherche pas a stopper le thread quand la fenêtre se ferme, la synchro sera faite et je ne pense pas que cela soit un problème, par contre tu risques du coup de déplacer le problème à la fermeture de l'application.
- Le point au dessus implique un effet secondaire : le fait de ne pas stopper le thread fait que si l'utilisateur réouvre immédiatement la même fenêtre, le code du thread va être exécuté une deuxième fois sans que la première exécution soit finie. Il faut donc protéger le code de cette potentielle double exécution, un sémaphore devrait être la solution (à tester) https://doc.pcsoft.fr/fr-FR/?3077013.
- Il faudrait aussi mettre en place un mécanisme empêchant la fermeture de l'application tant que le thread n'est pas fini.

L'autre piste est stopper le thread proprement. Il faut pour cela mettre en place un indicateur dans la boucle de traitement du thread qui demande au thread d’arrêter le traitement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
POUR TOUT sdResultat
si demandeArret alors
    SORTIR
fin

et tu positionnes demandeArret à vrai dans le code principal. Par contre, ici aussi un problème potentiel, c'est que si la requête en début de thread prend beaucoup de temps, le thread ne pourra pas être interrompu avant la fin de la requête.

-------
Dans les 2 cas, il me semble qu'il serait préférable de gérer le thread manuellement : https://doc.pcsoft.fr/fr-FR/?3077004. Cela permet de lancer le thread, mais surtout de connaître son état fini ou pas.

Le pseudo code serait donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ProcédurePrincipale
ThreadExécute("Thread1", threadNormal, ProcédureThread)

ProcédurePrincipaleArret
demandeArret = vrai
tant que ThreadEtat("Thread1") = threadEncours
  threadPause(10)
fin

ProcédureThread
tant que vrai
  si demandeArret alors
    sortir
  fin
fin