Discussion :

[OnePoint]

Bonjour à tous,

Par curiosité, j'ai voulu vérifier si le contexte hyperfile courant est conservé lorsqu'on crée un thread avec la fonction CreateThread de l'API Windows, au lieu de la fonction WLangage ThreadExécute.

Eh bien, ça ne fonctionne pas.
J'en conclus qu'il n'est pas du tout possible de partager une source de données entre 2 threads, ni même une requête ou une table ouvertes.

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

C'est clairement une impossibilité technique.

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.

[Hibernatus34]

Par curiosité, j'ai voulu vérifier si le contexte hyperfile courant est conservé lorsqu'on crée un thread avec la fonction CreateThread de l'API Windows, au lieu de la fonction WLangage ThreadExécute.

Excellente idée ! Je regrette même de ne pas y avoir pensé moi-même.
Je suppose qu'en interne la structure qui associe un nom de requête à ses données est locale au thread.
En tout cas, c'est vraiment impossible, pour le coup...

[niko9600]

Et pourtant dans la fonction Wlangage il y a l'option "ThreadContexteGlobal" qui donc, on est d'accord, ne sert à rien ? ou ne fonctionne pas ?
l'aide dit :

Mode de lancement du thread : Force l'utilisation du contexte global du projet si le thread est exécuté depuis une fenêtre.
Par défaut, le contexte de la fenêtre est utilisé.

Ou alors je n'ai pas bien compris et en fait cela veut dire que c'est le contexte global qui est dupliqué au lieu du contexte de la fenêtre. Et donc dans les 2 cas c'est bien un contexte dupliqué... ?

[Hibernatus34]

Non, cette option n'a rien à voir.

C'est pour que la fonction ne soit pas appelée avec le contexte de la fenêtre en exécution au moment de l'appel (depuis une fonction de fenêtre par exemple) :
- Mot clé MaFenêtre
- Possibilité d'appeler des fonctions de la fenêtre sans préciser le nom de la fenêtre
- Accès aux variables et champs de la fenêtre, toujours sans préfixer
- Suppression du thread si la fenêtre se ferme
...
Enfin, dans ma liste, je ne suis pas sûr de tout ce que l'option annule...

[niko9600]

Ok, bon au final étant donné que nous avons vu que c'était impossible d'utiliser une source de donnée commune dans 2 thread je met le sujet en "résolu" et j'adopte la solution du fichier temporaire qui est la plus simple au niveau code. Dans le cas ou on ne peut créer de fichier, la solution avec le tableau de variant est une bonne alternative.

Merci à tous pour votre aide, je vais écrire une requête à PC Soft à ce sujet, n'hésitez pas à faire de même.

[Hibernatus34]

Ma solution préférée (que je n'ai pas encore développée) reste l'idée d'une classe qui s'occupe de la synchro et du transfert des données.
Imaginez ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
clReq est CRequêteThread
sdReq est Source de Données
 
clReq.Exec("SELECT .....")
clReq.Termine() // Fait des Multitâche() jusqu'à la fin d'exécution, une méthode clReq.EstTerminée() permettrait aussi de laisser réellement la main à l'appelant
clReq.LitPremier(sdReq)
TANQUE PAS clReq.EnDehors()
    TableAjouteLigne(TABLE_Toto, sdReq.IDToto, sdReq.Libelle)
    clReq.LitSuivant()
FIN

Ce code est tout à fait possible. La classe est un poil complexe à écrire correctement, mais une fois que c'est fait, c'est aussi performant et léger que possible, et facile à utiliser.

On peut aussi imaginer une copie de tout le résultat dans la source de destination, mais ça gaspille de la mémoire. En contre-partie, ça permet d'utiliser les fonctions WinDev qui font elles-mêmes le parcours.

[niko9600]

Mais tu va avoir le même problème, même au sein d'une classe comment vas tu faire le lien entre la source de donnée du thread et la source de donnée qui va lire les données ?

[Hibernatus34]

Bien sûr que non. Le but de la classe est de se charger du problème :

Le thread qui exécute la requête fait ceci :
1. Exécuter la requête
2. Lire chaque ligne de la requête en attendant un signal à chaque itération, et partager les données dans des membres de la classe (tableau de variants par exemple)

L'interface de la classe (donc le thread principal) fait ceci :
1. Lancer le thread d'exécution (méthode Exec)
2. Attendre un signal du thread d'exécution ("la requête est exécutée")
3. Pour chaque ligne de résultat, envoyer un signal au thread d'exécution, attendre sa réponse et lire le contenu

Pour que le contenu soit disponible dans une source de données, il y a des astuces.
Par exemple, un simple SELECT 0 AS Numero, CAST('chaîne' AS VARCHAR) AS Nom, CAST('2014-01-01' AS DATE) AS DateCreation (sans clause FROM) fonctionne en SQL Server.
On le fait sur le "LitPremier", puis on se contente de modifier le buffer de la source de données à chaque "LitSuivant" (au lieu de ré-exécuter un SELECT à chaque ligne).

Des fonctions "magiques" comme celle-là, j'en ai plein mes projets. En cherchant bien, on peut faire des choses surprenantes avec WinDev...

C'est sûr, il faut utiliser des indirections, des HListeRubrique, gérer les différents types de colonnes... Mais personnellement j'ai déjà beaucoup de fonctions de ce type pour SQL Server, donc ça me paraît assez vite fait.

[niko9600]

oui donc tu passe bien par un tableau de variants... C'est la même méthode mais étoffé pour ne pas avoir a créé des procédures avec lancées par les thread etc mais plutôt une classe et ses méthodes.
C'est vrai qu'une fois que la classe est créé ça peut être pas mal à utiliser

[Hibernatus34]

Oui, mais c'est lu plus tôt et ça occupe moins de mémoire.
C'est un tableau de variants à 1 dimension.
La solution précédente est à 2 dimensions.
Et puis on bénéficie d'une syntaxe claire grâce à la source de données qui sert de buffer.
Bref, c'est plus performant et plus facile à utiliser.