Discussion :

[elghers_hocine]

Salam
Comment Récupérer la valeur d'une colonne "Nom" d'une table "Employé" d'une ligne précise "Matricule=10001" ?
Merci

[Guardian]

En lisant l'aide pour commencer
Tu y trouveras l'information pour utiliser l'indice de la ligne dont tu veux récupérer l'information

[gardangel]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// Sans commentaire (ça c'est bizarre)
SI Poseur_Question = "Paresseux"
nNBColonne = TableOccurrence(uneTable,toColonne)
// Parcours des lignes avec le fameux "_A_"
POUR Indice = 1 _A_ uneTable..Occurrence
	// Parcours des colonnes
	POUR niColonne = 1 A nNbColonne
		sUneColonne = TableEnumèreColonne(uneTable,niColonne)
		SI ({sUneColonne, indChamp}..Nom = "Nom") et ({sUneColonne, indChamp}[Indice] = "Matricule=10001")
 
		FIN		
	FIN
FIN

[Guardian]

Code :

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

1
2
// Sans commentaire (ça c'est bizarre)
SI Poseur_Question = "Paresseux"

[zouzoukha]

[J0r_x]

deux boucles pour récupérer la valeur d'une cellule, niveau optimisation c'est pas top.
Il existe la fonction tablecherche() :

Code :

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

1
2
w_indice_ligne = tablecherche(Employé.Matricule,10001)
w_valeur = Employé.Nom[w_indice_ligne]

[Nicolas_Jeanneau]

J'aime cette réponse

[gardangel]

J0r_x

1) Fais le test et compares le temps réponse... Sois surpris;
2) "Matricule=10001" porte a confusion et me laisse croire à un paramètre HTTP;

J'aurais du ajouter un Sortir de boucle...

Jean-François

[dedaelus]

J0r_x

1) Fais le test et compares le temps réponse... Sois surpris;
2) "Matricule=10001" porte a confusion et me laisse croire à un paramètre HTTP;

J'aurais du ajouter un Sortir de boucle...

Jean-François

Jean françois n'a pas tort. Il faut savoir qu'en wlanguage, la boucle POUR TOUT est particulièrement optimisé. Un ingénieur pcsoft me 'lavait expliqué lors d'une formation (bah oui ^^) et j'ai procédé a de nombreux test depuis. ET le POUR TOUT l'emporte presque toujours (bien que le hfiltre sur fichier soit aussi rapide pour hyperfile).

Par contre jox a pas tort sur l'économie de lignes de code. On revient toujours à la séparation entre lisibilité et performance

[hpascal]

Bonjour

On revient toujours à la séparation entre lisibilité et performance

On peut avoir les deux en codant ses propres fonctions

[dedaelus]

Bonjour


On peut avoir les deux en codant ses propres fonctions

certes mais la, on passe dans une considération efficacité absolue versus temps passé

[hpascal]

Le temps passé en factorisation est vite amorti par la "ré-utilisabilité" du code

Il faut bien sur que ça en vaille la peine, si c'est juste pour gagner 3 ms dans un traitement ce n'est le cas

[gardangel]

Bah, pour l'économie de temps, suffit d'en faire une procédure globale avec de jolis petits paramètres... On y pense une fois, on code une fois, voilà.

Il y a dix ans, mon premier mentor m'avait dit ceci : "un programmeur, c'est une personne paresseuse qui tend toujours vers la paresse".

Et rien... jamais rien n'est absolu.

Jean-François

[OnePoint]

Salut !

Je suis un peu stupéfait à la lecture de votre échange.

Apparemment, vous trouvez "acceptable" qu'une fonction "built-in" soit moins performante qu'une procédure codée par vous même et fonctionnellement équivalente (c'est à dire qu'elle n'a pas de valeur ajoutée en terme de fonctionnalité ou de robustesse).

Pour ma part, je ne trouve pas ça acceptable...

[R&B]

+1 @ OnePoint
En outre notre jeune ami n'aura certainement pas compris que dans le monde WinDev, une table est un champ de fenêtre.... et l'amalgame son homonyme du coté de la base de données a, semble-t il échappé à tous.

On reprends donc :
Comment Récupérer la valeur d'une colonne "Nom" d'une table "Employé" d'une ligne précise "Matricule=10001" ?

Code :

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

1
2
3
4
cNom est une chaine
SI hLitRecherchePremier(EMPLOYE,MATRICULE,"10001") ALORS cNom = EMPLOYE.NOM
 
// Voila la variable cNom contient le nom ou rien !

[hpascal]

...
Apparemment, vous trouvez "acceptable" qu'une fonction "built-in" soit moins performante qu'une procédure codée par vous même et fonctionnellement équivalente (c'est à dire qu'elle n'a pas de valeur ajoutée en terme de fonctionnalité ou de robustesse).

Pour ma part, je ne trouve pas ça acceptable...

@OnePoint : Là je suis entièrement d'accord, il faudrait remonter l'info au support car sinon il n'y a pas de raison que ça change. Entre temps on fait comme on peut pour contourner les choses inacceptables ...

Ceci dit je n'ai pas testé la différence de performance entre les deux modes de recherche énumérés ci-dessus

@R&B : Effectivement elghers_hocine ne parlait peut être pas d'un champ table.
Mais je crois qu'il a lâché le sujet ...

[gardangel]

One Point

Ce qui est acceptable est une notion très relative... Je serais curieux de voir le code C++ en arrière de certaines fonctions. On pourrait être surpris de constater les raisons qui en font de certaines "moins" robuste. Pour la flexibilité peut-être ? Une notion d'incompétence peut-être (les programmeurs débutants, chez PCSoft, codent les fonctions primaires...qui sait ?).

Pour R&B, ton affirmation est valide dans le contexte où l'applic est connectée sur une BD "fichier windev". En attendant un serveur, chez nous, j'utilise la messagerie Outlook comme "BD" temporaire... une petite applic jettable pour faire des suivis d'items sur le terrain (immo + contrat). Pas de BD "fichier" mais une gestion de courriels... Le défi est plus grand quand vient le temps de "plugger" mes données sur les zones du formulaire ET de l'état. Et pas question d'utiliser des fichiers (ou "table en windev") pour le moment.

J'ai répondu "généralement" à la question...

Jean-François