J'ai utilisé des champs LIB.
Si je les remplace par des champs SAI, cela fonctionne beaucoup mieux.
Normal ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
J'ai utilisé des champs LIB.
Si je les remplace par des champs SAI, cela fonctionne beaucoup mieux.
Normal ?
Les solutions les plus simples sont les plus efficaces
Salut!
Tu as 95 appels sur un code qui met plus de 4s!
Faudrait voir ce code pour comprendre ce qui met tant de temps!
Oui zouzoukha, c'est bien ce que j'ai vu aussi.
Le code est on ne peut plus basic :
Dans cette version, le champs LIB que j'utilisais avant, sont devenus des champs SAI.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Depuis , plus de problème.
En résumé, mon problème vient du type de champ. C'est normal selon toi ?
Les solutions les plus simples sont les plus efficaces
Salut,
Je ne vois pas quelle différence cela ferait d'interagir avec des libéllés ou des champs de saisie!
Essaie de modifier la condition de sélection de la table pour voir ce que cela donne?
[QUOTE=lololebricoleur;8143815]
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16PROCEDURE AfficheInfoClient() //On vérifie si la table n'est pas vide ou aucun client n'est sélectionné SI TableSelect(TABLE_CLIent) <= 0 ALORS SAI_Nom = "Aucun client n'est sélectionné" SAI_adr = "..." SAI_tel = "..." SAI_mobile = "..." SAI_mail = "..." SINON SI TABLE_CLIent.COL_CLI_Civilite <> "" ALORS SAI_Nom = TABLE_CLIent.COL_CLI_Civilite + " " + TABLE_CLIent.COL_CLI_Prénom + " " + TABLE_CLIent.COL_CLI_Nom SINON SAI_Nom = TABLE_CLIent.COL_CLI_Prénom + " " + TABLE_CLIent.COL_CLI_Nom SAI_adr = TABLE_CLIent.COL_CLI_Adresse + RC + TABLE_CLIent.COL_CLI_CP + " " + TABLE_CLIent.COL_CLI_Ville SAI_tel = TABLE_CLIent.COL_CLI_Tel_Fixe SAI_mobile = TABLE_CLIent.COL_CLI_Tel_Mobile SAI_mail = TABLE_CLIent.COL_CLI_Mail FIN
Cela ne change rien zouzoukha
D'ailleurs, j'ai poussé le test plus loin encore en réduisant le code à sa plus simple expression pour réduire le champ des possibilités
Plus de test, plus de procédure et simplification des données affichées.
En gros, il ne reste que 5 lignes de code pour la maj de champs en repiquant les données directement dans la table
Et bien le résultat est le même :-(
C'est effectivement troublant mais la seule chose qui fasse effet c'est de remplacer les LIB par des SAI.
Les solutions les plus simples sont les plus efficaces
Tu peux aussi désactiver l'affichage de la fenêtre quand tu mets à jour tes champs, puis le réactiver à la fin.
Dans certains cas ça accélère le traitement.
Tatayo.
Merci de l'info Tatayo ;-)
C'est quand même étonnant cette différence de traitement entre les champs LIB et SAI non ?
Les solutions les plus simples sont les plus efficaces
Ca peut aussi venir du fait que le champ lib est une chaine de caractère quel que soit le contenu alors que le champ de saisie est typé. Je suppose que tu as mis comme type celui du champ dans ta base de données ?
Intéressante ta question Nicolas,
Dans ma base de données, j'ai précisé la nature des valeurs (si c'est bien cela que tue appels "typé"). Dans le cas c'est principalement des textes.
Et tu penses que cela pourrait expliquer la lenteur ?
Pourquoi selon toi ?
Et comment le vérifier ?
Merci
Les solutions les plus simples sont les plus efficaces
Envoyé par zouzoukha
Bonjour,
Qu'elle est l'intérêt de faire appel à cette procédure 95 Fois ?
Elle ne devait être appelée qu'en qu'a de sélection d'une ligne, non ?
Je pense que si WinDev doit transformer chaque valeur de type entier, numérique, date, etc ... en chaine cela va provoquer un temps de traitement supplémentaire d'où ma question. Si tu as des champs de type de chaine et que tes libellés sont de type chaine, cela ne devrait pas trop changer dans ce cas, encore que le type des libellés soit peut-être différent, je ne sais pas ???
L'idée est de conserver le type du champ dans la zone de saisie ou le libellé pour qu'il n'y ait pas de conversion à faire.
Bonjour,
Il serait intéressant de connaître les résultats de l'analyse de performances dans cette dernière version.
Je suppose que les 19 appels de la première analyse correspondent bien à la sélection consécutive de 19 lignes et non à un affichage de 19 lignes.
La procédure elle-même peut être simplifiée, tant en code qu'en lisibilité.
- Le test (ligne 4) TableOccurrence(TABLE_CLIent) = 0 OU TableSelect(TABLE_CLIent) = -1 est inutile :
a priori, cette procédure est appelée au coup par coup et ne peut donc être appelée que si les deux conditions sont réunies (il existe des lignes et l'une d'elles a été sélectionnée)
La "mise à blanc" de la zone "Informations" relève de l'initialisation ou d'une réinitialisation de la fenêtre.- Le test sur la civilité (ligne 11) SI TABLE_CLIent.COL_CLI_Civilite <> "" est inutile :
On peut tout afficher sans s'en soucier, puisque la zone est soit vide (c'est ce que l'on teste) soit remplie.
Le problème de l'espace orphelin qui existerait en début de ligne peut être résolu soit en supprimant les espaces en début de ligne, soit en ajoutant systématiquement un espace à la colonne civilité lorsqu'elle est remplie.
Hemgé
Merci pour vos contributions
Le champ lib reste plus long à traiter qu'un champs sai, même à type de donnée égal.
Les 19 appels correspondent effectivement au fait que j'ai lancer l'analyseur et que j'ai répété plusieurs fois la même opération donc le résultat est normal
Je note les suggestions d'optimisation Hemgé, c'est toujours bon à prendre. Mais ce n'est pas ça qui fera la différence.
En plus, le test TableOccurrence(TABLE_CLIent) = 0 OU TableSelect(TABLE_CLIent) = -1 dans la mesure ou ma table accepte les saisie en cascade et que, de ce fait, j'ai déjà eu des soucis qui suppose ce test.
Le test de la civilité, je le garde car je ne suis pas fan de l'ajout d'un espace directement dans la donnée mémorisée mais je note l'approche néanmoins.
En l'état, j'ai réglé le problème puisque je suis passé avec des champs SAI.
Mais c'est chiant de ne pas maitriser la bête
Les solutions les plus simples sont les plus efficaces
Bonjour,
Il resterait néanmoins intéressant de voir à combien vous êtes revenu.
A l'évidence.Je note les suggestions d'optimisation Hemgé, c'est toujours bon à prendre. Mais ce n'est pas ça qui fera la différence.
Je ne comprends pas très bien, parce que, comme écrit, si la ligne est sélectionnée, c'est qu'elle existe...En plus, le test TableOccurrence(TABLE_CLIent) = 0 OU TableSelect(TABLE_CLIent) = -1 dans la mesure ou ma table accepte les saisie en cascade et que, de ce fait, j'ai déjà eu des soucis qui suppose ce test.
Donc, si votre test corrige quelque chose, ce quelque chose vous a échappé, n'est pas identifié et pourrait avoir d'autres répercussions.
Cela reste toujours interpellant.
Vous opérez votre concaténation à partir des valeurs intermédiaires stockées dans les colonnes de la table et pas directement à partir des rubriques du fichier.Le test de la civilité, je le garde car je ne suis pas fan de l'ajout d'un espace directement dans la donnée mémorisée mais je note l'approche néanmoins.
Et je vous proposais en fait d'agir sur la valeur intermédiaire " en ajoutant systématiquement un espace à la colonne civilité lorsqu'elle est remplie."
Hemgé
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager