Discussion :

[droliprane]

Salut,

Pour ce cas précis j'ai pour habitude de créer un thread pour lancer la requête.
Je laisse 1 seconde entre chaque "frappe" modification du champ.( donc tant que j'écris la requête n'est pas lancé)

Bonsoir, ça m'intéresse de savoir comment tu fais pour laisser cette fenêtre de 1 seconde pour une éventuelle nouvelle touche appuyée, avant de lancer le thread de remplissage de la table.

D'autre part, ça ne pose pas de problème de manipuler un champ de l'ihm (la table) depuis un thread secondaire ?

Merci à toi

[zouzoukha]

Salut!

Ci-joint une fenêtre de recherche multi critères Clients.



Dans le code de modif des 5 champs de recherche j'ai mis le code suivant :

Code :

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

TimerSys(Controle_Touche,150,1)

Et voici le code de ma procédure Controle_Touche :

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
46
47
48
49
50
51
52
53
54
55
56
57
58
PROCEDURE Controle_Touche()
 
sSql est une chaîne
sdReq est une Source de Données
 
sSql=[
SELECT
CLIENT.IDCLIENT,
CLIENT.Code,
CLIENT.Nom,
CLIENT.NomPersonne,
CLIENT.Prenom,
CLIENT.Ville,
CLIENT.Activité,
CLIENT.Adresse,
CLIENT.Patente
 
FROM CLIENT
 
WHERE
 
Code LIKE %1
AND Nom LIKE %2
AND NomPersonne LIKE %3
AND Prenom LIKE %4
AND Ville LIKE %5
 
ORDER by Nom
]
 
sSql=ChaîneConstruit(sSql,"'%"+SAI_RECH_CODE+"%'",...
							"'%"+SAI_RECH_SOCIETE+"%'",...
							"'%"+SAI_RECH_NOM+"%'",...
							"'%"+SAI_RECH_PRENOM+"%'",...
							"'%"+SAI_RECH_VILLE+"%'")
 
//info(ssql)
 
SI PAS HExécuteRequêteSQL(sdReq,hRequêteDéfaut,sSql) ALORS
	Erreur("ERREUR Requête Client "+HErreurInfo(hErrComplet))
SINON
	TableSupprimeTout(TABLE_CLIENT)
	POUR TOUT sdReq DEPUISDEBUT
		//Remplissage de la table
		TableAjoute(TABLE_CLIENT,...
		sdReq.IDCLIENT+TAB+...
		sdReq.Code+TAB+...
		sdReq.Nom+TAB+...
		sdReq.NomPersonne+TAB+...
		sdReq.Prenom+TAB+...
		sdReq.Ville+TAB+...
		sdReq.Activité+TAB+...
		sdReq.Adresse)
	FIN
FIN
HAnnuleDéclaration(sdReq)
 
FinTimerSys(1)

A adapter au besoin...

Bon DEV

[droliprane]

Formidable ce système

Combiné à une légère simplification de mon interface (juste pour ce qui est de la partie interro factures qui était un peu trop alambiquée) et c'est parfaitement fluide !

Je suis en train d'appliquer ce mécanisme un peu partout dans mes écrans

Une question par contre, comme chacune de mes fenêtres est susceptible de se retrouver ouverte en simultané dans un système d'onglets, faut-il que le numéro du timer soit à chaque fois différent des autres fenêtres ?

Encore merci à tous pour vos précieux conseils

[michel.souris]

J'y pense que maintenant mais avez-vous créé des indexes full-text sur les références de vos produits et le noms de vos clients ? Je pense que ça améliorera grandement les temps de réponse...

[droliprane]

J'y pense que maintenant mais avez-vous créé des indexes full-text sur les références de vos produits et le noms de vos clients ? Je pense que ça améliorera grandement les temps de réponse...

Bonjour Michel,

je ne sais pas positionner des index dans SQL Server, je sais que je dois me pencher sur le sujet

Mais d'un autre côté comme je n'arrive pas à me rendre compte de l'impact que cela aurait d'indexer tel ou tel champ, je n'ai pas trop investigué de ce côté là

J'ai bien lu ce papier (http://sqlpro.developpez.com/cours/quoi-indexer/) mais je n'ai pas l'expérience ou le feeling pour sentir ce qui doit être indexé et ce qui ne doit pas l'être

[michel.souris]

Indexer ce qui est utilisé pour les recherches me semble une bonne optique.
Voici la page MSDN sur la création d'index sur SQLServer : http://msdn.microsoft.com/fr-fr/library/ms188783.aspx

Je peux vous assurer que les temps de recherches ne seront plus comparable (allez, à la louche votre requête de 12 secondes en prendra 2... et encore)

Très bon (comme d'habitude) article de SQLPro !

[droliprane]

Bonjour,

finalement le principe du TimerSys(calcul, 1) est sympa mais pas magique. Je post ici plutôt que de rouvrir un autre sujet parce que c'est très lié.

En fait, quand je lance la procédure via TimerSys je ne peux rien faire d'autre qu'attendre la fin de son exécution. Or ça peut prendre parfois une bonne dizaine de secondes, et surtout parfois la procédure se lance sans attendre 1s car c'est après avoir modifié une date dans un calendrier, donc pas d'intérêt d'attendre 1s pour une éventuelle autre touche entrée.

J'aimerais donc que l'exécution de la procédure lancée par TimerSys ne soit pas bloquante au niveau de l'ihm et laisse à l'utilisateur la possibilité d'affiner ses critères de recherche alors même que la procédure de calcul est en exécution.

Comment dois-je m'y prendre svp ?

Merci à vous

[Tober]

Ce post est sacrément riche en chemin divers !
Simplification d'interfaces, optimisation de requêtes, indexation...

Le problème de base n'est toujours pas réglé il me semble et la base de ton problème est le requetage.
Tu as dis plus tôt qu'une de tes requêtes prenait 55s pour deux jointures !

Code :

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

1
2
3
SELECT count(*) FROM 
fc INNER JOIN (SELECT DISTINCT fcl_fc_id FROM fcl WHERE fcl_art_reference LIKE '%dor%') fcl_temp ON fc_id = fcl_temp.fcl_fc_id
INNER JOIN (SELECT clt_id FROM clt WHERE clt_code LIKE '%at%') clt_temp ON fc_client = clt_id

Sans parler de la construction de la requête qui est vraiment ... moche, quelles tailles font les tables ? 10, 100,1000, 100000 lignes ?

Comme dit plus haut, pour faire une requête, il faut d'abord créer l'ensemble de tables et ensuite faire la clause where et pas tout mélanger bizarrement.
Dans ton cas, une requête comme ça serait plus juste même si je ne connais pas très bien tes tables... :

Code :

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

1
2
3
4
5
6
7
SELECT count(*) 
-- L'ensemble
FROM fc 
INNER JOIN fcl ON fc_id = fcl_temp.fcl_fc_id
INNER JOIN clt ON fc_client = clt_id
-- Les conditions
WHERE fcl_art_reference LIKE '%dor%' and clt_code LIKE '%at%'

Tout simplement.
Si le distinct sur fcl sert à quelque chose, alors tu peux transformer la requête comme ça :

Code :

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

1
2
3
4
5
6
7
8
SELECT count(fc_id) 
-- L'ensemble
FROM fc 
INNER JOIN fcl ON fc_id = fcl_temp.fcl_fc_id
INNER JOIN clt ON fc_client = clt_id
-- Les conditions
WHERE fcl_art_reference LIKE '%dor%' and clt_code LIKE '%at%'
GROUP BY fc_id

Pour récapituler, avant de se concentrer sur des optimisations et des économies de bout de chandelles, il faut d'abord se poser la question de quel est le problème.
Je te laisse tester la requête et voir que ça devrait aller beaucoup plus vite que 55s. Sinon, il y a une autre source à ton problème qu'on ne voit pas car on ne connait pas ton modèle de données, l'état du server SQL...
Exemple de problème possible : tes tables peuvent être liées par plusieurs IDs.

J'espère que ça a pu t'aider.

[droliprane]

Bonjour,

après avoir passé en revue 90% de mes requêtes en les réécrivant correctement avec des instructions de jointures plus académiques, je rencontre encore quelques lenteurs de traitement sur des calculs complexes.

l'exemple qui me tracasse est dans mon cas la modification d'une donnée technique de fabrication (typiquement le coût horaire de fonctionnement d'un département, ou une cadence de production) qui doit engendrer le recalcul du coût des opérations de fabrication concernées (ayant lieu à ce département, ou dont la cadence a changé) ce qui potentiellement peut entrainer un changement du cout global de fabrication d'un article A (si le coût d'une de ses opérations à changé, alors forcément le coût de fabrication de l'article en question change aussi), et ce changement de coût article doit à son tour se répercuter sur le coût des articles employant l'article A dans leur nomenclature de fabrication...

Aussi, ces modifications de données techniques, même si elles ne sont pas fréquentes, ont lieu quotidiennement au minimum et à chaque enregistrement ce recalcul complexe s'exécute et peut prendre une à deux minutes selon le nombre d'articles impactés.

J'ai utilisé l'analyseur de performance, et après ré-écriture de mes requêtes, la majeur partie du temps d'exécution concerne des "traitement interne au moteur d'exécution". Donc j'imagine que c'est du côté du serveur SQL que je dois maintenant investiguer pour optimiser les performances. A cet effet, j'aimerais rentrer en contact avec des personnes qui pourraient m'aider à apporter des optimisations sur ma BDD, notamment au niveau de l'indexation.

Merci d'avance