GrowGeorges a écrit:

Depuis que j'ai découvert les fonctions setfilter() et filter() des datawindow je n'utilise plus que ça, au détriment
de la méthode habituelle de mes coworkers qui font un getsqlselect(), charcutent la pauvre chaine et lui assemblent
des tumeurs au bout pour obtenir le résultat souhaité et wop setsqlselect(), retrieve().

Pouark!

GrowGeorges a écrit:

On m'a parlé d'une plus grande rapidité pour la méthode setsqlselect() et une plus grande fiabilité lorsqu'il s'agit d'applications
tournant sur beaucoup de postes car la requete est regénérée, (ceci dit rien ne m’empêche de faire un retrieve avant mon filter() ...)

Enfin voilà, j'voulais avoir votre précieux avis amis PBusers ;)

Quelques points :

- plus grande rapidité : bench pour étayer ça ? Parce PB n'est pas très bon en natif pour jouer avec les chaînes, setsqlselect nécessite une recompilation de la requête... alors que le setfilter travaille directement au niveau de la machine virtuelle DW (l'interpréteur qui est dans pbdwexxx.dll).

- d'un autre côté le filtre, c'est comme le tri (setstort()), ça travaille sur les données déjà descendues de la base. Il est sûr que si il ya beaucoup de données il vaut mieux limiter au niveau de la requête que de filtrer après, mais moi je ferais ça avec des retrival arguments, au moins la requête n'est pas recompilée pour changer les critères.

- plus grande fiabilité : c'est plutôt subjectif... fiabilité envers les bugs glissés par le programmeur ? au lieu d'avoir un bug dans le filtre, on peut avoir un bug dans la manipulation de chaîne, ou une farce du système quand les réglages linguistiques ou le système du client sont différents du poste de dev (cas vu chez un client chinois : Asc retourne -1 (non documenté) sur des caractères exotiques)... juste pour dire

GrowGeorges a écrit:

Depuis que j'ai découvert les fonctions setfilter() et filter() des datawindow je n'utilise plus que ça, au détriment
de la méthode habituelle de mes coworkers qui font un getsqlselect(), charcutent la pauvre chaine et lui assemblent
des tumeurs au bout pour obtenir le résultat souhaité et wop setsqlselect(), retrieve().

J'espère qu'ils ne contrôlent pas une centrale nucléaire ou des missiles atomiques, avec des dev comme ça, tes co-workers

- on construit dynamiquement les sql, qu'on exploite avec SyntaxFromSQL mais jamais en bricolant avec get/setsqlselect
- SetFilter() / Filter() en interne dans des traitements
- pour un truc agréable à l'utilisateur PowerFilter qui est une surcouche au SetFilter() standard.

rincevent a écrit:

C'est infâme de faire ça avec des retrieves car tu vas chaque fois solliciter la DB et le réseau uniquement pour faire un filtre sur des données que tu as déjà récupérées.

Bah ça a son utilité pour disons une liste de commandes accessible a de nombreux opérateurs, par exemple faudrait pas qu'un gus vois sa commande comme 'éditable' parce que lorsqu'il est entré
sur sa fenêtre elle était dans cet état mais dans l'intervalle un autre gus l'a 'traité' .

Oui j'parle avec mes mots et ça a du sens pour moi ! :D

GrowGeorges a écrit:

rincevent a écrit:

C'est infâme de faire ça avec des retrieves car tu vas chaque fois solliciter la DB et le réseau uniquement pour faire un filtre sur des données que tu as déjà récupérées.

Bah ça a son utilité pour disons une liste de commandes accessible a de nombreux opérateurs, par exemple faudrait pas qu'un gus vois sa commande comme 'éditable' parce que lorsqu'il est entré
sur sa fenêtre elle était dans cet état mais dans l'intervalle un autre gus l'a 'traité' .

Oui j'parle avec mes mots et ça a du sens pour moi ! :D

Oui là je décèle une utilisation rauisonnable d'un "Re Select" parceque tes rows sont susceptibles d'avoir changés entre le retrieve et l'update mais bon ça tu nous l'avais pas expliqué au départ. (ou j'ai mal lu, possible)

Je vais enfoncer une porte ouverte et sans doute pas t'avancer plus mais j'ai envie de dire que quand on veut FILTRER on utilise SetFilter() / Filter(), et quand on veut rafraichir les données récupérés là on peut faire un re-select

faut juste savoir déterminer ce qu'on doit/veut faire exactement.

Je dirais qu'il serait mieux de faire un Retrieve( critere1, critere2, ... ), comme çà tu ne remonte que les données nécessaires et ce sans patcher à la mano tes SQL.

Maintenant si tu as besoin de tripatouiller d'autres lignes dans le filtered buffer, c'est autre chose.

GrowGeorges a écrit:

Ok mais moi je veux filter mes row tout en m'assurant qu'aucune mis a jour n'a été faite sur ma BD,
dans ce cas faire un getsql(), setsql(), retrieve()
                    ou un setfilter(), filter(), retrieve()

c'est tout bon pareil ?

ouep

Ouaich dommage que c'est payant le PowerFilter... ( $99.95 )

Dernière modification par rincevent (15-01-2013 16:00:36)

ouch ok, j'avais bien vu le purchase mais j'pensais que c'était juste un lien pour un achat de licence pb !
J'vais plutot m'abstenir alors ^^

Je reviens vers vous après avoir constater d'étranges soucis de lenteur au niveau de mes retrieve et en particulier lors de l'utilisation de setsqlselect ...

Voici le test que jai mis en place :

afin de calculer le temps de retrieve je recupere les temps entre le début de l'event retrievestart et le debut de l'event retrieveend (grace a un now() qui stocke les valeurs dans des variables locales).
J'ai mis en place quelques autres boutons : 'retrieve' qui fait uniquement un retrieve de la data, 'temps' qui calcule et m'affiche la diff de temps et enfin 'setsql' qui va simplement concatener la requete initiale
avec une chaine ' where col1=val1 and col2=val2 '

J'arrive sur la fenetre, premiers tests juste sur le bouton 'retrieve' : mes rows sont affichées pour un temps moyen de 0.400s
Maintenant, appuie 1 fois sur 'setsql' puis tests répétés sur 'retrieve' : mes rows sont affichées pour un temps moyen de 3.700s

Et euh bah conclusion : je suis perplexe.

Mon avis : si avant de faire le premier retrieve(), aucun setsqlselect() n'est fait, la requête est déjà sous forme compilée dans la DW.
Après un setsqlselect() la requête sql doit être traitée (recompilée) pour que la DW sache quoi faire avec. Il est probable que ce soit le temps supplémentaire constaté.

C'est pour ça que je disais que le filter() se limitait à travailler sur l'affichage ou non d'enregistrements, il ne nécessite pas de recompilation de la requête associées à la dw. (Bien que le filtre soit une expression sql, il est probable que le moteur de DW sache l'interpréter directement sans tout recompiler)

Quelques éléments en plus, parce que attendre 3 à 4 secondes pour un utilisateur c'est quand même impensable :

Les deux colonnes du critère 'where' concernent une table qui est en 'left outter join' dans ma requete, si en revanche
je modifie mon 'where' pour qu'il cible plutot deux colonnes de la table du 'from' les trois tests présentés ci dessus ont tous
des résultats équivalent (0.5sec en moyenne).