Discussion :

[zycomatic]

Bonjour à tous, je suis confronté à un problème qui tiens davantage de la méthodologie que de la "technique" pure et dure ! Je m'explique :

Je dois réaliser (sur CR bien entendu, sinon j'aurais posté ailleurs) un tableau récapitulatif mensuel de relevés de compteurs (type eau, gaz...)

j'ai donc une base (ORACLE pour ne pas la nommer) qui contient des compteurs et pour chaque compteur, une liste de relevés.
je dois donc afficher plusieurs fois le même champs (ex. VALEUR_RELEVE) avec différents paramètres (typiquement : VALEUR_RELEVE pour le compteur A01, VALEUR_RELEVE pour le compteur A02, etc... pour environ 50 compteurs)

De plus il me faudra bien souvent appliquer une formule savante à chacun des compteurs pour avoir un résultat cohérent
ex.
la consommation d'eau = (VALEUR_RELEVE du compteur A01 - VALEUR_RELEVE du compteur A02)xCoef
mais pour celà l'éditeur de formule ou de sélection devrais pouvoir faire l'affaire.

Ma question concerne plutôt le moyen de récupérer chacune des VALEUR_RELEVEE pour un traitement indépendant dans mon etat.

Je ne peux pas utiliser l'expert sélection car ce dernier applique un filtre à l'ensemble de l'état.

Je ne vois alors pas d'autres solutions :

1. Créer une "commande" SQL pour obtenir chaque VALEUR_RELEVE souhaitée

exemple :
SELECT VALEUR_RELEVE FROM MATABLE WHERE ID_COMPTEUR = A01 AND DATE...etc
et donc faire autant de commande SQL qu'il y a de compteurs(presque 50 je le rapelle)

J'ai essayé cette solution, tout simplement en créant une commande SQL dans l'expert base de données, seulement voilà quand je prends le champ de l'explorateur de champs et que je le colle dans mon etat, j'obtiens une zone vide en aperçu.
(pour info, si je fais un clic droit > parcourir les données du champ sur l'objet inséré dans mon rapport, je vois bien la valeur résultant de ma requête SQL).

2. faire autant de "sous-etats" qu'il y a de VALEUR_RELEVE à récupérer (est-ce seulement envisageable de faire un sous-etat par compteur?).

bref, je me dis que je ne dois pas avoir la bonne méthode !

Est-ce que quelqu'un peut m'aider à appréhender la chose ? En espérant avoir été assez clair dans mes explications...

Merci d'avance

CL

[Aitone]

Bonjour,

Tout ne vient que d'une seule table ?

Je mets un frein tout de suite pour un sous-état par compteur car le temps de traitement de l'état sera vraiment énorme ?

Je ne suis pas sûr d'avoir saisi le problème mais est-ce que les variables ne feraient pas l'affaire ?

[zycomatic]

Tout d'abord, merci pour la réponse.

La compteurs sont biens dans une seule base (1 table compteurs liée à 1 table relevés)

Je vais creuser du côté des variables...

je reviens vers le forum si je ne m'en sors pas..

à bientôt probablement !

CL

[say]

quel est exactement le traitement que tu dois faire avec ces valeurs?

[zycomatic]

Sorry Say ... Je n'avais pas vu la question !

Alors comme l'a dit un corse célèbre : mieux vaut un petit schéma qu'un grand discours, c'est pourquoi je joins une image commentée du type de rapport que je doit réaliser.



Comme vous pourrez le constater, chaque valeur subit un traitement spécifique (addition, multiplication, division...), tout ce que j'ai réussi à faire avec Crystal jusqu'à lors c'est regrouper mes relevés par ID compteur, filtrer par date (ou période) et leur appliquer un traitement (ex : les multiplier par un Coef), seulement c'est le même traitement qui est répéte pour chaque relevé...

En effet, pourvoir récupérer la valeur d'un relevé (via un recordset ???) pour la stocker dans une variable me permettrait de réaliser mon rapport sauf que je ne sais pas du tout comment m'y prendre...

merci d'avance pour l'aide que vous pourrez m'apporter...

CL

Je vais maintenant mener une vie exemplaire afin qu'un jour je puisse être réincarné en chat.... Déjà que j'enviais le mien de paresser toute la journée

[say]

Désolé du retard...mais les notifications de dvp m'arrivent en retard.

t'en es où? ça semble bien galère ton état là.... :s

[zycomatic]

Je ne t'en veux aucunement pour le retard, c'est déjà sympa de t'intéresser au problème !!!

A vrai dire mon problème n'as pas beaucoup avancé, la seule optique que j'ai aujourd'hui est de créer autant de sous-rapports que j'ai de relevés compteurs.

Afin d'éviter trop de lourdeurs, ma donnée sera qualifiée avant son intégration dans Crystal, ce qui fait que je n'aurais à priori pas de "calcul" à faire dans mes requête, qui se contenteront de me renvoyer la valeur d'un compteur pour une période donnée.

Je vais donc faire un test grandeur nature pour voir si le temps de génération du rapport avec tous ses sous-états est acceptable.

dans le cas contraire, je ne pourrais passer que par un développement spécifique qui me permettra de disposer d'une table de données "propres" à l'exploitation que je souhaites en faire dans Crystal.
Je risque donc de revenir solliciter ce forum très bientôt.

CL

[zycomatic]

Salut,

Je reviens à la charge avec mon rapport Crystal et cette fois-ci une question (à priori) plus simple.

Voilà je souhaiterais réutiliser un champ de paramètre dans plusieurs sous-rapports (un peu comme une variable).

Dans mon exemple chaque compteur est "préfixé" d'un nombre indiquant un bâtiment, l'idée étant qu'à la génération du rapport on demande à l'utilisateur de choisir le bâtiment dans une liste et que le champ de paramètre découlant de ce choix puisse être utilisé dans plusieurs sous rapport.

c'est possible ça ? Et si oui, comment ?

Merci d'avance

CL

[zycomatic]

j'ai un peu avancé sur mon problème, apparemment la liaison liaison de sous-états me permet de récupérer un paramètre dans un sous-état sous la forme {?pm-?nomduparam}.

Mon problème est maintenant que lorsque j'essaie d'utiliser ce champ dans une requête SQL, il n'est pas "interprété", c'est à dire qu'il apparaît dans la requête SQL sous sa forme brute {?pm-?nomduparam}.... Du coup mon select ne fonctionne pas..

Avez-vous un indice ?

merci d'avance

CL

[zycomatic]

désolé, mais j'ai trouvé pourquoi ça ne fonctionnait pas, je mettais mon paramètre entre des quotes ... un long monologue pour une erreur de débutant.

CL

[say]

où en es tu alors?
Par ailleurs, merci de ne pas poster plusieurs questions dans le même topic... même si c'est le même projet pour toi.