Discussion :

[Amuny]

Bonjour tout le monde

Après plusieurs heures de recherche avec un collègue, je tente un petit post ici dans l'espoir de croisé encore une fois la route d'un expert en la matière

Donc le problème est plutôt simple, malgré que la solution ne semble pas l'être!

Nous tentons simplement de récupéré la différence entre deux DATE-TIME provenant d'Oracle, mais en retirant les minutes et les heures.

De faire la simple soustraction entre les deux dates est "fonctionnel": Le résultat est bon. Sauf que... le rapport prend soudainement 15-20minutes de plus a rouler

Avec la fonction _days_between intégrée dans Cognos, le calcul se fait presque instantanément. Sauf que adieu les minutes et les heures.

La question est donc; y a t-il un milieu pour garder une optimisation correcte tout en récupérant ces dites minutes et heures?

[Sunchaser]

Bonjour,

Si tu récupères bien 2 champs de type <Date> en provenance d'Oracle, je suis curieux de connaitre le traitement qui est fait dessus et qui rends le rapport si long.

[Amuny]

Bon, donc on a continuer a se creuser la tête un peu, et en ajoutant une troisième personne a la question on a réalisé un truc un peu bête,

Du coup on a remonté le calcul a la source plutôt qu'au bout des Joins: On gagne un temps précieux.

Par contre ca défile sur un autre problème de source... mystérieuse.

Le rapport s'exécute parfaitement en HTML, mais lorsqu'on l'exécute (ou même qu'on le converti à partir du rapport HTML) en PDF, alors là, le drame
Le rapport prend un gros 20-30minutes pour dire: Ah bah en fait... aucune donnée a afficher. Alors que le HTML renvoi les 230lignes. On prend le rapport pdf, on le renvoi en html: paf, nos 230 lignes.

Si j'enlève le champs de calcul de la date, hop, le pdf fonctionne

Voici le "calcul" en soit;

Code :

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

1
2
3
4
IF ([Date Fin Événement] is not null) THEN
([Date Fin Événement]-[Date Début Événement])
ELSE 
    ( null )

les deux dates étant les deux champs provenant d'oracle.

NB: Même en n'affichant pas le calcul sur le rapport, juste le mettre dans la requête, le pdf n'aime pas. Et apparemment Excel non plus d'ailleurs... (excel pas encore complété mais le délai laisse a désiré pour l'instant)

[Sunchaser]

Bonsoir,

"Amusant", comme comportement.
Pour comprendre ce qui se passe lorsque l'on passe de HTML a PDF, il serait alors intéressant de savoir comment et avec quoi est fait le rapport: quels objets ? Listes, crosstabs, ? etc ... utilisant d'objets de type HTML Item ?
Qui est en master-detail avec qui ?, etc

Mais j'oublie aussi un truc important: quelles versions du produit ?

Sinon, je trouve que le fait de penser que l'on peut passer "sans dommage" de HTML a PDF est une mauvaise idée, en général, et ce n'est pas une critique particulière contre toi; le fait de faire un rapport pour PDF demande un travail particulier, de même pour HTML, de même pour Excel, etc...

@+

[Sunchaser]

Oups, j'oubliais aussi:
. lorsque le rapport tourne en PDF et ne "sort rien", que se passe t il exactement ? Page blanche / PDF vide ? Message d'erreur ?

Il y a t il un message particulier d'enregistré dans cogserver.log ?

++

[Amuny]

Bonsoir,

"Amusant", comme comportement.
Pour comprendre ce qui se passe lorsque l'on passe de HTML a PDF, il serait alors intéressant de savoir comment et avec quoi est fait le rapport: quels objets ? Listes, crosstabs, ? etc ... utilisant d'objets de type HTML Item ?
Qui est en master-detail avec qui ?, etc

Mais j'oublie aussi un truc important: quelles versions du produit ?

Sinon, je trouve que le fait de penser que l'on peut passer "sans dommage" de HTML a PDF est une mauvaise idée, en général, et ce n'est pas une critique particulière contre toi; le fait de faire un rapport pour PDF demande un travail particulier, de même pour HTML, de même pour Excel, etc...

@+

C'est des guillemets bien placés, on se dit la même chose ici
C'est une simple liste formé de plusieurs jointures avec que des données élémentaires.

Usager =>
========> Jointure 1
Adresse =>

Evenement =>
=========> Jointure 2
Cadre =>

Jointure 1 =>
=========> Rapport
Jointure 2 =>

La version: Cognos 8.4

Les date provenant de la table d’évènement


Et je n'ai jamais cru le contraire pour l'histoire des formats. Je suis conscient que Excel, ou PDF, ne font pas le même traitement que le HTML avant d'arriver a l'affichage. Mais c'est quand même curieux que de passé de 320 lignes a.... 0 Le tout par l'ajout d'un seul champ de calcul de dates

Je continue activement de chercher une solution, mais pour l'instant en vain

EDIT: Sans le mettre nulle part, je créer le champs de type donnée élémentaire ayant comme valeure DateFin - DateDebut sur la requete événement: PDF ne fonctionne plus.
Je CTRL+X sur le champ, execute : PDF Fonctionne
CTRL+V ramene le champ, execute: PDF fonctionne plus.

C'est donc assez clair net et précis que c'est ce maigre petit champ de soustraction de date qui lui en fait voir de toutes les couleurs (ou pas justement vu que c'est tout blanc...), reste a savoir pourquoi et surtout comment y pallier

EDIT pour l'edit que je viens de voir;
La page PDF s'affiche en disant "Aucune donnée a affiché", exactement comme... comme si je faisais la même requête avec des paramètres bizarre.

[Amuny]

J'en suis au recherches avec notre DBA préféré.

Première découverte:
Cognos n'envoie pas du tout le même SQL lors d'une requête HTML que lors d'une requête PDF. Par contre, PDF et Excel semblent la même chose.

Hors il s'avère qu'a quelque part la requête générée pour PDF/Excel n'est pas très... optimale? Ce qui finit par crasher, et donc renvoyé aucune donnée puisque le SQL plante.

L'histoire de la date à effectivement son impact. Apparemment, ce petit champ module complètement la requête envoyée... et la rend complètement désaxée.
Ce qui n'est pas le cas avec la requête HTML qui ne semble tout simplement pas affectée.

Donc on continue de regarder, ça ira surement a demain vu l'heure. Mais on tiens la piste; ce vilain petit champ module la requête de manière... étrange.