Discussion :

[niko9600]

Bonjour,

Je souhaite exécuter une requête un peu lourde dans un thread secondaire, le coup classique.

je fait la déclaration de la source dans l'initialisation de la fenêtre pour qu'elle soit globale, puis j'envoie un postmessage quand le traitement est terminé pour executer l'affichage de la requete dans une table de la fenêtre. Le traitement est lancé depuis un bouton de la fenêtre.

Seul hic j'ai toujours un message d'erreur me disant que la source de donnée est introuvable !

A la lecture de l'aide et de divers forum cela n'est pas si incohérent étant donné qu'il est bien écris qu'une source est liée à son contexte HFSQL.
Hors le thread secondaire duplique le contexte ! donc je ne vois pas comment je peut, hors du thread secondaire, récupérer mes données ...

Je suppose pourtant qu'il doit y avoir une solution toute simple, pour une utilisation aussi basique...

[Hibernatus34]

C'est un des gros problèmes des sources de données.
Elles sont locales au thread.
Il y a des solutions toutes plus lourdes et lentes les unes que les autres. (notamment partager un buffer dans lequel on fait transiter les données, ou bien appeler ExécuteThreadPrincipal à chaque ligne)
Si quelqu'un en a une plus simple, je suis aussi preneur.

[niko9600]

A la limite je pensais à un fichier temporaire pour faire plus simple mais bon, il doit bien y avoir un moyen avec une sdd !?

[jurassic pork]

hello,

Je souhaite exécuter une requête un peu lourde dans un thread secondaire, le coup classique.

peut-être une réponse nulle de ma part, mais pourquoi pas ne pas laisser la requête s'exécuter dans le thread principal et empêcher le blocage de l'IHM par un multitache négatif comme ceci par exemple :

Code :

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

1
2
3
4
5
6
HExécuteRequêteSQL(MaRequête, hRequêteDéfaut, Code_MaRequête)
TANTQUE MaRequête..ExécutionTerminée = Faux
//trace( HNbEnr(MaRequête, hNonBloquant))
Multitâche(-10)
FIN
Trace ("Fin de requête")

Ami calmant, J.P

[Hibernatus34]

HExecuteRequêteSQL est non-bloquant uniquement pour HF.
Pour ceux qui utilisent OLE DB ou les accès natifs, c'est pas possible.

[niko9600]

Bonjour,

On dévie un peu du sujet original mais c'est lié. En fait lorsqu'on arrivera sur le TantQue c'est que la requête est executée/terminée... donc on ne rentrera jamais dans le TantQue puisque la condition sera toujours vraie.

C'est le même problème si on souhaite par exemple annuler une requête un peu trop longue, étant donné que cela bloque sur le HexecuteRequeteSQL(), on a pas moyen par code dans le même thread d'annuler la requête (à mon humble connaissance en tout cas..). Pour l'instant en mode test le seul moyen que j'ai trouvé est de retourner dans windev et d’arrêter le test avec le bouton correspondant dans l'ongle "code".

Pour revenir au sujet de départ, tout le problème semble venir de ce foutu "contexte HFSQL"...

[niko9600]

en effet je ne l'ai pas stipulé mais ma requête est sur un AS400 en ODBC, d'où le blocage de HexecuteRequeteSQL().

[niko9600]

en regardant bien ce n'est pas clair dans l'aide. Car le contexte HFSQL n'est censé contenir que les filtres, vues ouvertes etc..

Mais il est écrit dans l'aide "principe d'execution des thread" que les objets type variable entre autre sont communs :

Accès aux éléments existants et contexte HFSQL
Lors de la création d'un thread, toutes les déclarations, objets, éléments existants sont communs :

- au nouveau thread secondaire.
- au thread dans lequel le thread secondaire a été créé (dans la plupart des cas, correspond au thread principal).

Ces threads peuvent ainsi accéder aux variables, procédures, ... Toutes les variables créées après le lancement d'un thread sont accessibles uniquement dans le thread où elles sont créées.

donc en théorie ma source de donnée créée dans le thread principal devrait être accessible depuis le thread secondaire (d’ailleurs elle l'est d'un coté puisque je peut faire mon HexecutRequeteSQL avec cette source globale). Mais une fois revenue dans le thread principal pour afficher les résultats de la requête, toujours le même message d'erreur comme quoi la source de donnée n'est pas accessible.. J'ai essayé en déclarant le thread secondaire avec "threadcontextglobal" et l'erreur est toujours là.
Donc finalement le problème ne viendrai pas du contexte HFSQL mais bien de la manipulation de la source de donnée dans les 2 threads..

quelqu'un a-t-il une solution ?

[Hibernatus34]

donc en théorie ma source de donnée créée dans le thread principal devrait être accessible depuis le thread secondaire (d’ailleurs elle l'est d'un coté puisque je peut faire mon HexecutRequeteSQL avec cette source globale).

C'est une illusion.
La seule chose que porte une variable de type "source de données" c'est le nom d'une "requête" (terminologie WinDev).
Ce nom est global au code, et local au thread.

Donc sdToto dans une fonction est juste un objet de manipulation de "sdToto", une "requête" globale, mais locale au thread.
Le "requête" est créée lors de l'exécution de HExécuteRequête.

C'est extrêmement mal fichu.

Pour résumer :
- sdToto, même en variable locale, manipule la même source de données que ce soit dans une fonction ou dans une autre, du moment que c'est dans le même thread.
- gsdToto, utilisé dans deux threads différents, et même si c'est une variable globale, désigne 2 sources de données différentes (celle du thread 1 et celle du thread 2).

Ca fait 2 raisons de vouloir modifier le comportement des sources de données... Chose que PC Soft peut très bien faire. cf. Description de projet, onglet "Compilation", où vous trouverez quelques corrections du même genre.
Alors envoyez une demande au support technique.

[niko9600]

Est-ce qu'on peut dans ce cas convertir une source de donnée ou le jeu de donnée en fichier externe facilement ? c'est à dire sans connaitre à l'avance le nombre et type de rubriques. On pourrait ainsi utiliser ce fichier externe pour alimenter la table dans le thread principal.

J'ai fait un Hcréation(sdSrcReq) juste après le HexecuteRequeteSQL pour tester, et cela semble fonctionner : le traitement dure quelques secondes ce qui est logique vu la taille du jeu de donnée, et Hcréation renvoie "vraie". Mais impossible de trouver le fichier ! (j’espérai trouver un sdSrcReq.fic dans le REP...). Dans le cas d'un fichier externe il faudrait normalement faire auparavant un Hdécritfchier et Hdécritrubrique etc..
Mais c'est impossible pour moi car le nombre de rubrique varie d'une requête à l'autre.

A moins qu'il existe une fonction ou un moyen plus simple de créer facilement un fichier (ou autre objet qui n'aura pas le problème des duplications pour chaque thread) d'où je puisse récupérer les données dans le thread principal ?

[Hibernatus34]

Personnellement, j'ai écrit cette fonction avec un tableau à 2 dimensions de Variants.
Les 2 gros soucis sont :
- La performance (temps de la copie + occupation mémoire)
- La lisibilité (accès par un numéro de colonne)

On peut utiliser un tableau de tableaux associatifs pour accéder avec le nom de colonne.
On peut aussi développer une classe qui permet de lire le résultat de la requête en "dialoguant" avec le thread d'exécution. (le thread se termine réellement quand on a lu la dernière ligne, à travers la classe)
Ou bien on peut passer en paramètre une procédure "callback" à appeler avec ExécuteThreadPrincipal.
etc.

Notez que je suis encore en WD18. Il y a peut-être des nouveautés en WD19 qui pourraient servir.

Une suggestion à faire à PC Soft : au moins rajouter une option "hAvecMultitâche" dans HExécuteRequêteSQL pour que WinDev fasse des Multitâche() pendant l'exécution et que l'appli n'ait pas l'air d'être plantée. Voire "hAvecMessageAttente".

[niko9600]

oui mais je peux avoir pas mal de colonnes, et ce nombre étant variable je ne vois pas trop comment faire.

J'ai essayé avec HexportXML, ça marche bien et c'est très rapide. Le fichier XML est vraiment propre avec tous les noms de colonne etc.
Par contre pour le ré importer dans une table c'est plus compliqué... car il faut déjà avoir déclaré un fichier avec les rubriques donc même HIC ! quel dommage qu'on ne puisse pas l'importer dans une source de donnée

[jurassic pork]

J'ai essayé une autre méthode en utilisant sqlexec et sqltable dans le thread principal , au point de vue performance, je ne pense pas que cela soit terrible et il faut que la table à remplir soit une table mémoire pour utiliser sqltable. Le principe : je boucle en lisant 1000 enregistrements à la fois dans la boucle il y a un multitâche. Je n'ai pas de base externe donc j'ai essayé avec une connexion à une analyse voici le code :

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
Code_MaRequête est une chaîne = 
[
SELECT 
tsn,	
completename,
unit_name1
FROM 
taxinomie
]
x est un entier = 0 
ResSQL est un entier = 0
//Connexion SQL sur une base HF (C/S ou non : avec les infos de l`analyse)
ResSQL=SQLConnecte("F:\Mes Projets\DB_Taxinomie\DB_Taxinomie.WDD", "", "")
SI ResSQL=0 ALORS
	SQLInfoGene()
	Erreur("Echec de la connexion SQL à l`analyse",SQL.MesErreur)
	RETOUR
FIN
ResSQL = SQLExec(Code_MaRequête, "Requête1")
SI ResSQL ALORS
	// Traitement  
	Table1..AffichageActif = Faux
	// Récupération par groupe de 1000 lignes
	TANTQUE SQLTable(1000,"Requête1", Table1, "ColTitre", "90")
	Trace(x)
	x +=1000
	Multitâche(-10)
	FIN
	Table1..AffichageActif = Vrai	
	SINON
		// Erreur SQL
FIN
Trace("Fin")

A hibernatus qui a fait un article dans le forum sur les performances de sqlexec et HexecuteRequeteSQL de dire ce qu'il en pense. Moi je ne suis qu'un novice en base de données

[Hibernatus34]

oui mais je peux avoir pas mal de colonnes, et ce nombre étant variable je ne vois pas trop comment faire.

J'ai essayé avec HexportXML, ça marche bien et c'est très rapide. Le fichier XML est vraiment propre avec tous les noms de colonne etc.
Par contre pour le ré importer dans une table c'est plus compliqué... car il faut déjà avoir déclaré un fichier avec les rubriques donc même HIC ! quel dommage qu'on ne puisse pas l'importer dans une source de donnée

Avec un tableau de variants à 2 dimensions, le nombre de colonnes peut être variable. Avec les autres solutions que j'évoque aussi. Elles sont même meilleures et je les mettrai en place dès que j'aurai un peu de temps pour ce type de développement.

Pour le tableau de variants, ça peut donner ça dans le thread :

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
PROCEDURE gTHREAD_ExecReq(sSQL)
sdReq est Source de Données
nNbEnr est entier
nNumLigne est entier
tabRub est tableau de chaînes
 
Dimension(gtabReqMultitâche, 0, 1)
gbReqMultitâcheOK = HExecuteRequêteSQL(sdReq, hRequêteSansCorrection, sSQL)
SI PAS gbReqMultitâcheOK ALORS
	gsErreurReqMultitâche = ErreurInfo()
	RETOUR
FIN
gsErreurReqMultitâche = ""
// Sauvegarde du résultat de la requête dans un tableau de Variants à 2 dimensions
nNbEnr = HNbEnr(sdReq)
SI nNbEnr > 0 ALORS
	ChaîneVersTableau(HListeRubrique(sdReq), tabRub, RC)
	Dimension(gtabReqMultitâche, HNbEnr(sdReq), TableauOccurrence(tabRub))
	HLitPremier(sdReq, hSansRafraîchir)
	nNumLigne = 0
	TANTQUE PAS HEnDehors(sdReq)
		nNumLigne++
		POUR i = 1 _A_ TableauOccurrence(tabRub)
			SI {sdReq + "." + tabRub[i], indRubrique}..Null ALORS
				gtabReqMultitâche[nNumLigne, i] = Null
			SINON
				gtabReqMultitâche[nNumLigne, i] = {sdReq + "." + tabRub[i], indRubrique}
			FIN
		FIN
		HLitSuivant(sdReq)
	FIN
FIN

Dès que le thread est terminé, on sait que le tableau de variants est disponible.
Sinon, on peut faire un peu de synchro et permettre de le lire au fil de l'eau (mais dans ce cas, il vaut mieux utiliser une file comme buffer et la vider au fil des lectures).
Enfin, comme je le disais plus haut, il y a pas mal de possibilités. Il faut faire preuve d'inventivité.

En SQL Server, on peut écrire SELECT ... INTO #Toto FROM ...
Si vous avez l'équivalent sur votre SGBD, ça peut être une autre solution.

jurassic pork : Le problème n'est pas la lecture des lignes de résultat, mais l'exécution de la requête.

[jurassic pork]

jurassic pork : Le problème n'est pas la lecture des lignes de résultat, mais l'exécution de la requête.

Le sqlexec est bloquant avec une base non HF ? Comme je n'ai pas pu essayé et que je me suis trompé dans la lecture de la doc PCSOFT :

Résultat : Vrai si la requête a été exécutée, Faux dans le cas contraire. L'exécution de la requête est asynchrone : la fonction demande l'exécution de la requête puis le traitement en cours continue à s'exécuter sans que le résultat de la requête ne soit récupéré.
Le résultat de la fonction SQLExec permet uniquement de gérer les problèmes de connexion. Il est conseillé de tester la bonne exécution de la requête dans la procédure <Nom de la procédure>.

mais c'était pour "Exécuter une requête SQL en code Navigateur donc pour webdev. Honte à moi

[jurassic pork]

hello,

oui mais je peux avoir pas mal de colonnes, et ce nombre étant variable je ne vois pas trop comment faire.

J'ai essayé avec HexportXML, ça marche bien et c'est très rapide. Le fichier XML est vraiment propre avec tous les noms de colonne etc.
Par contre pour le ré importer dans une table c'est plus compliqué... car il faut déjà avoir déclaré un fichier avec les rubriques donc même HIC ! quel dommage qu'on ne puisse pas l'importer dans une source de donnée

Pourquoi ne pas utiliser Hversfichier au lieu de HexportXML ?
dans le thread quand la requête est terminée par exemple faire :

Code :

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

1
2
HVersFichier(MaRequete1,"f:\Temp\MonFichier.fic")
SendMessage(Handle(Fenêtre1),2324,0,0)

et sur réception du message dans la fenêtre faire par exemple un truc du genre:

Code :

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

1
2
3
4
5
6
HDéclareExterne("f:\Temp\MonFichier.fic", "tempWD")
Fenêtre1.Table1.col1..LiaisonFichier =  "tempWD.rub1"
Fenêtre1.Table1.col2..LiaisonFichier = "tempWD.rub2" 
Fenêtre1.Table1.col3..LiaisonFichier = "tempWD.rub3" 
....
Fenêtre1.Table1..FichierParcouru = "tempWD"

Ami calmant, J.P

[niko9600]

Merci Jurassic pork, c'est exactement la fonction simple que je cherchait pour exporter une source de donnée !!

Ca marche nickel, par contre l'attribution par colonne ne me vas pas car le nombre change et de plus il y a beaucoup plus simple :

Code :

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

1
2
3
 
HDéclareExterne("c:\test.fic","TEST")
ConstruitTableFichier(TABLE_Test,"TEST", taRemplirTable)

et j'ai bien toutes les colonnes avec les titres de colonnes que j'ai mis dans le requête SQL. Du coup je peux faire n'importe quelle requête et n'importe quelle table cela fonctionnera, j'aurais toujours une belle table avec les bons titres de colonne.

Je reste toujours ouvert à une solution en utilisant uniquement les sources de données, afin d'éviter de créer un fichier temporaire...

[Hibernatus34]

J'ai donné des idées de solutions plus haut, mais je dois parler chinois... Après, j'avoue ne pas porter d'intérêt à des choses comme ConstruitTableFichier. Pour utiliser cette fonction, la seule bonne solution est le fichier temporaire, qu'il soit client comme ci-dessus, ou serveur, comme avec un SELECT ... INTO #Toto en SQL Server par exemple.

[niko9600]

Hibernatus,

en effet j'ai vu tes solutions et je t'en remercie, mais c'est vrai qu'elles sont complexes et là je fait la même chose en 2 lignes. Je ne les utiliserai que si je ne trouve rien de mieux. Je cherche toujours le code le plus simple possible sauf si je n'ai vraiment pas le choix. ConstruitTableFichier est tout simplement magique (je rêvais de ce genre de fonction quand je bossais sur Access), et ça marche aussi avec des sources de données, pas forcément un fichier externe (même si dans notre cas tu as raison cela implique d'utiliser la solution du fichier externe).

[Hibernatus34]

Pas de souci. J'ai tellement l'habitude de me faire des fonctions pour ce genre de choses, que j'oublie qu'on n'a pas toujours le temps/les moyens. A terme, souvent, ça vaut quand même le coup si c'est bien fait et simple à utiliser.