Discussion :

[ggbbii]

Bonjour,

Voilà mon soucis:
J'ai une requête SQL Server qui me renvoie 250.000 enregistrements et il faut qu'ils soient tous affichés dans un tableau.
Lorsque j'exécute la requête via SQL Server Management Studio, le résultat (donc les 250.000 lignes) s'affichent en 1-2 secondes.
Lorsque j'exécute cette même requête via Windev pour l'insérer dans un tableau windev, l'affichage prend environ 15-20 secondes (Que j'utilise SQLTable() ou 250.000 fois TableAjouteLigne()).
Y'a-t-il moyen d'afficher ces résultats (la totalité des résultats) plus rapidement?
Ou bien est-ce que la fonction Windev SQLTable() est tout simplement plus lente que la façon dont SQL Server Management m'affiche les résultats et je ne pourrais pas avoir mieux?
Comme on a pas accès au code C++ qui se cache derrière la fonction SQLTable(), je ne sais pas pourquoi ce traitement est si long.

Merci par avance

[tatayo]

Bonjour,
Le temps constaté est juste celui qui est nécessaire pour faire transiter les lignes sur le réseau.
Si tu regardes bien Management Studio, il ne lui faut qu'une seconde pour afficher les PERMIERS enregistrements. La récupération continue en tâche de fond.

Tu peux peut-être gagner un (tout petit) peu de temps en désactivant l'affichage de la table le temps du remplissage.
Sinon tu peux aussi faire ce dernier dans un thread secondaire*, ainsi l'application reste active le temps du chargement.

Tatayo.

*: normalement un thread secondaire ne doit pas agir sur l'affichage, mais dans les faits ça fonctionne. Tu peux aussi récupérer tes lignes dans un tableau de structure, et baser la table sur ce tableau.

[dsr57]

Bonjour

Regardes du coté de la propriété AffichageActif.
Désactives là avant l'appel de la fonction SQLTable et réactives là après.

Bon dev

EDIT : je rejoins Tatayo, j'ai été plus lent à écrire ma réponse

[hpascal]

Bonjour

L'utilisation du fetch partiel permet de donner l'impression que l'affichage est immédiat (hors temps d'exécution de la requête bien sur)

Je reprends l'exemple de la page d'aide de SQLTable :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
// Transfert dans table : récupération par Fetch
ResSQL = SQLExec("SELECT NOMCLI,PRENOMCLI,VILLE FROM FACT", "REQ1")
SI ResSQL ALORS
        // Récupération par groupe de 28 lignes
        TANTQUE SQLTable(28,"REQ1", TABLE_MATABLE, "ColTitre", "90")
 
        FIN 
SINON
       // Erreur SQL
FIN
SQLFerme("REQ1")

[Invité]

je pense que tu pourrais gagner un peu plus de temps en changeant ta requête de sélection, tu exécutes à la place une procédure stockée qui contient justement ta requête de sélection (si besoin est, tu ajoutes des paramètres à ta procédure stockée), puis avant de commencer à remplir ton champ table, tu utilises AffichageActif, et enfin, pour remplir, tu utilises SQLTable.

[ggbbii]

Le problème ne vient pas de la requête ou du temps de transit des infos sur le réseau.
Faire un fetch sur la table ne résoud pas mon problème car j'ai besoin qu'elle soit alimentée dans sa totalité.
En passant pas mal de temps à creuser, je me suis rendu compte que le sqltable() (ou tableAjouteLigne()) était 2 fois plus long lorsque je l'exécute dans un thread.
Le problème: si je ne l'exécute pas dans un thread, je bloque ma fenêtre!!!

[darkWD]

C'est le temps nécessaire à l'affichage des 250.000 lignes dans le tableau qui est long. Je ne pense pas que les tableaux (table) de windev ont été pensé de façon à afficher rapidement un tel nombre de ligne. tout comme la plus part des IDE.
Ce que je peut te conseiller, c'est de prendre ton mal en patience et d'encadrer ton script avec un sablier.
Un autre conseil, évite de mettre la pression sur les thread secondaires. Je ne sais pas pour les dernières version de WD, mais ça peut générer un bug lié à l'adressage mémoire sur certains postes. En tout cas, si tu te retrouve avec un bug incompréhensible du genre "GPF access violation" tu saura d'ou il vient.

[hpascal]

Faire un fetch sur la table ne résoud pas mon problème car j'ai besoin qu'elle soit alimentée dans sa totalité.

En utilisant le fetch ça alimente toute la table. Le principe c'est que ça l'alimente bloc par bloc et c'est toi qui choisis la taille du bloc
En ajoutant un Multitache(-1) dans la boucle du fetch ton application ne sera pas bloquée.
Ensuite pour choisir la taille du bloc (en nombre de lignes) c'est à toi de tester en fonction de la réactivité souhaitée. Si le bloc est petit l'application est plus réactive mais le remplissage dure un peu plus longtemps, en augmentant la taille de bloc la table sera alimentée plus rapidement mais l'application sera moins réactive. Il faut trouver le bon compromis.

Code :

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

1
2
3
4
5
6
7
8
9
10
// Transfert dans table : récupération par Fetch
ResSQL = SQLExec("SELECT NOMCLI,PRENOMCLI,VILLE FROM FACT", "REQ1")
SI ResSQL ALORS
        // Récupération par bloc de 500 lignes
        TANTQUE SQLTable(500 ,"REQ1")
             Multitache(-1)
        FIN 
SINON
       // Erreur SQL
FIN

En passant pas mal de temps à creuser, je me suis rendu compte que le sqltable() (ou tableAjouteLigne()) était 2 fois plus long lorsque je l'exécute dans un thread.
Le problème: si je ne l'exécute pas dans un thread, je bloque ma fenêtre!!!

Il est interdit de manipuler l'interface dans un thread. Si parfois ça peut sembler fonctionner ça peut générer des plantage violents

[Lo²]

Il est interdit de manipuler l'interface dans un thread. Si parfois ça peut sembler fonctionner ça peut générer des plantage violents

Ce n'est pas le sujet, navré, mais j'utilise régulièrement des threads secondaires pour remplir des tables et je n'ai pas encore rencontré de problème.
En effet, dans l'aide, il est indiqué que les threads ne sont pas à être utilisés pour l'IHM, mais bon.

[hpascal]

Ce n'est pas le sujet, navré, mais j'utilise régulièrement des threads secondaires pour remplir des tables et je n'ai pas encore rencontré de problème.
En effet, dans l'aide, il est indiqué que les threads ne sont pas à être utilisés pour l'IHM, mais bon.

Je t'avoue que moi aussi je l'ai fait, c'est quand même bien pratique.
Jusqu'à ce qu'un jour j'ai eu des erreurs fatales dans une application qui se sont arrêtées immédiatement en désactivant le thread.
Alors depuis je ne fais plus. Autant ne pas se créer des problèmes Ce n'est pas pour rien que PCSOFT demande de ne pas le faire
Le fetch partiel m'a permis d'avoir un comportement satisfaisant en terme de performance et de réactivité.

[zouzoukha]

Salut,

@hPascal
J'exécute dans mon code un Hexecuterequetesql sur une base HF pour alimenter une table mémoire avec 6000 enregistrement et l'affichage prend 1 à 2 secondes.
Je souhaiterai avoir cet affichage instantanée du moins en impression avec ce fameux fetch.
Est il possible de l'utiliser avec un TANTQUE Hlitsuivant et non TANTQUE SQLTable(500 ,"REQ1") ?
Merci d'avance

[hpascal]

Bonjour

Soit tu utilises les instructions SQL... soit tu utilises les instructions H...
Donc si tu utilises un HExecuteRequeteSQL tu ne peux pas utiliser du SQLTable

De plus les fonctions SQL... sont faites pour les bases externes en ODBC (même si ça fonctionne avec tout autre type d'accès y compris HFSQL)

Dans ton cas, si tu dois remplir une table mémoire avec une source de données, tu peux utiliser FichierVersTableMémoire qui est plutôt efficace

et pas dans un thread bien sur

[zouzoukha]

Merci pour l'info HPascal.
Fichierverstablememoire n'oblige t-elle pas à rapatrier toutes les rubriques du fichier?
J'ai toujours évité cette fonction à cause de cette contrainte.

[hpascal]

Non. Comme son nom ne l'indique pas ça fonctionne aussi avec une requête éditeur ou code

Donc si tu utilises une requête dans le code HExecuteRequêteSQL, FichierVersTableMémoire pourra directement utiliser la variable source de données que tu as utilisé.
C'est d'ailleurs clairement indiqué dans la page d'aide

Cette fonction aurait du s'appeler "SourceVersTableMémoire"