Discussion :

[gallargues]

Bonjour,

Je dois rajouter un objet dans mon univers pour m'en servir dans les requetes de mes rapports.

Je voudrais que cet objet ait comme valeur la date du jour. mais ne soit pas lié à un champ de table.

Je travaille sous oracle donc j'avais pensé à sysdate... mais comment le definir en tant que variable.

Maintenant, il est peut etre possible de donner la date du jour au niveau des requetes de rapports.. en tant que constante.. mais je n'ai pas trouvé.

Merci de vos conseils.

[TomDuBouchon]

Bonjour,

Alors, différentes solutions :

• Au niveau du rapport : fonction DateCourante() sur versions 5.x et 6.x et DateActuelle() sur versions XI.
• Au niveau de l'univers : création d'un objet avec en SELECT : sysdate (sous Oracle). Attention cependant, la vérification renverra une erreur car l'objet n'est lié à aucune table. Néanmoins, il fonctionnera dans les requêtes s'il est utilisé avec d'autres objets.

[Zeusviper]

[*]Au niveau de l'univers : création d'un objet avec en SELECT : sysdate (sous Oracle). Attention cependant, la vérification renverra une erreur car l'objet n'est lié à aucune table. Néanmoins, il fonctionnera dans les requêtes s'il est utilisé avec d'autres objets.[/LIST]

Sous Oracle tu as la table dual pour éviter ca. Donc en créant une table dérivée

Code :

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

select sysdate from dual

Tu pourra récupérer l'objet sysdate, et tout reste valide.

Ceci est d'ailleurs assez pratique pour créer de petites tables de constantes directement dans l'univers!

[TomDuBouchon]

Tu pourra récupérer l'objet sysdate, et tout reste valide.

Très juste. Cependant si la table dérivée n'est liée à aucune autre table cela va générer un produit cartésien. (qui ne multipliera pas les lignes mais qui en sera quand même un). Donc selon le paramétrage de l'univers :

• Produit cartésien autorisé : aucune alerte,donc très dangereux pour d'éventuels autres cas dans l'univers.
• Autorisés avec alertes : une alerte à chaque rafraichissement, donc contraignant.
• Refusés : dans ce cas ça ne marchera pas.

Par contre, si on utilise cette valeur via une autre requête dans le rapport, pas de problème.