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.

[Amuny]

Et c'est reparti,

première remarque ce matin:
Notre table évènement contient un champ "Commentaire", qui est évidemment un champs très méchant dans un SQL.

Lors de la requête en HTML, Cognos fait une première requête récupérant toutes les informations, a l'exception de ce dit champs. Qui est récupéré dans une 2ie requête envoyée dans un deuxième temps qui récupère uniquement quelques petits détails et le commentaire avant de tout merger ca ensemble.

Hors, lorsqu'on tombe en PDF/Excel, il devient gourmand, et veut tout faire d'un seul coup. Et vu l'effet "intelligence" de Cognos, il me génère 2-3 Table Access Full sur ma table évènement... et là je vous dit pas le drame de passé une table de 800 000 enregistrements avec des gros champs de textes.
(@Toad: TABLE ACCESS FULL TABLE EVENEMENT. COST: 10 638 BYTES: 223 060 050 CARDINALITY: 669 850 )

Du coup oracle aime pas trop ça. Et le plantage renvoyant absolument rien, j'obtiens aucune données sur mes rapports, puisque Oracle ne renvoi rien.

Donc reste plus qu'a tester des trucs pour optimisé la requête cognos un peu, mais ca marche pas toujours comme on veut ce truc

Du coup je ne pense pas que quelqu'un du forum puisse spécialement m'aidé a moins d'un conseil d'optimisation général quelconque que je prendrais avec plaisir, mais je précise quand même ces informations dans le cas ou quelqu'un tomberait sur ce post que ca puisse l'aidé a comprendre ce qui ce passe.


Amuny,

[Sunchaser]

Bonjour,

Il est évident que, de mon côté et aux vues des faibles capacités d'abstraction de mon cerveau dans certains cas, sans avoir les données et les mains dans le cambouis, je vais avoir du mal a proposer une solution.

Néanmoins, je resterais sur l'idée que l'optimisation ne peut venir que côté données / SQL.
A priori, il n'y a pas de "gros" problèmes a demander a Oracle de sortir 800 000 lignes, un truc bien écrit doit pouvoir le faire; a l'inverse, une bouse mettra quinze plombes a sortir 10 lignes.
A priori on part d'une table qui contient des centaines de milliers d'enregistrements, pour arriver a un affichage de 230 lignes ... je vais enfoncer une porte ouverte la, mais on est bien sur que l'on filtre au plus bas niveau possible (avant n'importe quel calcul un peu complexe), et que les jointures sont ok ?

[Amuny]

Bonjour,

A priori on part d'une table qui contient des centaines de milliers d'enregistrements, pour arriver a un affichage de 230 lignes ... je vais enfoncer une porte ouverte la, mais on est bien sur que l'on filtre au plus bas niveau possible (avant n'importe quel calcul un peu complexe), et que les jointures sont ok ?

Problème trouver a ce niveau après des heures de recherches...

Ça fonctionne maintenant, le problème venait d'une jointure qui était un 1.1 alors que la seconde ou j'ai mis un 0.1, il s'est calmé. (Au niveau d'une jointure entre évènement et adresse)

Le comportement reste a mon goût assez étrange sachant que la requête était quand même complètement bousillée avec un champ de deux dates alors qu'elle fonctionnait sans, question de stabilité j'imagine, c'était la petite goutte qui faisait déborder le vase.

Erreur provenant donc de moi initialement faute d'attention, même si je reste impressionné du comportement de Cognos avec ses requêtes qui explosent avec l'ajout d'un champ

Le processus de recherche a quand même bien fonctionné, passé par Toad pour analyser la requête, ensuite voir ou il prenait le plus de jus pour validé ensuite les jointures liées a ces tables

Donc bien vu même sans capacité surhumaine d'abstraction, le problème initial était plus simple

Amuny,