Bonsoir,
J’ai besoin de pouvoir appliquer des axes d’analyse de type nombre d’occurrences renseignées/nulles pour le champ de l’axe ou nombre d’occurrence où la valeur d’un champ date est supérieur à la date du jour (indicateur on-track / delayed), … etc.
Les formules sont-elle la bonne approche ?
Si oui, je n’ai pas réussi à trouver dans la documentation ou le dispositif de training comment (bien) utiliser la fonction “formule” dans la définition des axes d’un tableau croisé…
Bruno
Les formules ont été laissées en friche depuis la version 3. De mémoire il y avait des limitations.
On va voir ce qui est utilisable dans le contexte de la 4.0+
Bon alors la logique en l’état c’est que la formule est appelée pour chaque cellule du tableau croisé avec les autres valeurs de la cellule (toutes converties en décimal) dans la variable values, le resultat de la formule étant lui même un décimal.
Ex:
Ca ne résiste donc pas bien aux changements d’ordre dans les valeurs (devenus possibles en 4.0)
En outre ça ne gère que des valeurs décimales.
Bref ça a besoin d’un lifting
NB: une contrainte front empêche l’enregistrement, ça va être corrigé (ça aussi c’est un truc qui n’existait pas en 3 - les contraintes front - et qui pose pb dans ce cas), on va pousser un patch ce soir pour corriger ça
PS: j’ai passé le post en “feature requets”
Merci beaucoup pour ton retour.
J’ai l’impression que le concept de formule ne permettra pas de répondre à mon besoin…
Quelle est la préconisation pour construire un tableau croisé qui affichera le nombre de record d’un objet ayant un champ renseigné / pas renseigné ? ou dans le cas d’un champ d’objet de type date, une date dépassée (< date du jour) ?
En effet, dans ce cas, la seule information restituée dans le tableau est la somme des cas renseignés / pas renseignés (pour simplifier) et la valeur renseignée n’est elle même pas remontée dans le tableau.
J’ai pour l’instant botté en touche en ajoutant un champ d’objet “technique” calculé non visible (et persistant en base) pour le premier cas d’usage (valeur renseignée ou pas) mais pour la comparaison avec la date du jour (qui change chaque jour), j’ai besoin de recalculer chaque record à chaque construction du tableau… mais d’une manière générale, dès lors que le résultat de la formule peut changer en fonction de la date du jour ou des données à chaque rendu du tableau, je sèche…
En principe on pourrait paramétrer des tableaux croisés sur des objets “select”.
J’ai essayé mais pour le moment le cas est visiblement pas bien géré (la requête select ... from (select ...) group by ... est mal construite ce qui génère une erreur SQL)
@Francois qu’en penses-tu ?
La requête d’un tableau croisé est un peu spéciale pour laisser les champs inutilisés à null, faire un group-by élémentaires pour les fonctions de base (count, avg, min, max) ou ensuite en java (moyenne géométrique…).
Créer un objet “select” qui prépare les données du jour me semble la bonne approche pour partir d’une vue pré-calculée des données sans persistance, car une fois les fields correctement mappés, le CT ne devrait y voir que du feu.
Par contre tous les SGBD n’aiment pas les “from (select …) alias”
On va regarder comment faire.
J’ai fait un test et cela fonctionne bien avec un objet “select”.
Il y avait juste un problème avec les TC éditables dans le cas d’un objet “select” sans clé fonctionnelle.
Mais cette notion n’existe pas en V4.
Exemple de champ calculé sur Oracle, j’ai créé un objet “select” :
select
row_id,
ord_quantity,
ord_total,
CASE ord_quantity WHEN 1 THEN '0' ELSE '1' END as bool1
from demo_order
'1' as row_id)
Ensuite j’ai créé un CT comme n’importe quel autre, dans mon cas j’ai utilisé le champ calculé (booléen vrai si qtté>1) en colonne :
Sinon on peut aussi utiliser un objet “normal” avec un champ sans colonne physique calculé au postSearch en fonction de la date du jour en Java (si le calcul ne peut pas faire via SQL avec sysdate ou équivalent now(), current_timestamp…).
Merci François pour ton retour.
Je vais considérer l’option de l’objet select ad-hoc pour ce report.
ps: J’avais tenté la solution de recalcul à la volée via le postSearch mais l’initialisation du tableau ne passait pas par ce hook (implémentation Rhino) donc la valorisation de se faisait pas.
