Discussion :

[Migraine]

Bonjour à tous,

cela fait un moment que je travail sur un environnement Desktop XIR2, avec DB2 comme BDD, et j'obtiens souvent des erreurs de calcul dans mes tableaux.

J'ai appris à jouer avec les ruptures, sections et autres outils permettant de recouper les données, cependant, il y a des moments ou BO fait de la merde... (Dsl je ne vois pas comment le dire autrement) Tous les experts BO que j'ai questionné m'ont toujours dis de laisser tomber et de chercher un autre moyen d'obtenir ce que je veux, mais la, y en a marre !
A défaut de pouvoir corriger et obtenir mon information, j'aimerais au moins comprendre pourquoi et dans quelle situation ce type d'erreur survient.

Actuellement, j'ai ce problème avec une somme de chiffres provenant d'une dimension d'un fournisseur de donnée (disons FD1), je recoupe cette info avec d'autres provenant d'un autre fournisseurs de données (FD2), je synchrone sur 3 dimensions afin d'avoir les bonnes corrrespondances (je suis sur de ma synchronisation) et je vois bien mes données parfaitement en correspondance entre fournisseur, seulement, en faisant la somme, j'obtiens ce #ERRI.

je me souviens aussi avoir rencontré d'autre code erreur du même type... Comme #ERR etc... Je suis preneur égalemen^t.

Quelqu'un peut-il m'aider à retourver l'origine de ce problème ? Ou le contourner intelligemment ?

merci d'avance.

[Julien59]

Bonjour,
Le code #ERRI veut tout et rien dire
On peut t'éclairer si tu nous en dis un peu plus sur tes requêtes, ton calcul d'indicateur, ton tableau (section? Rupture? etc...)
Là comme ça, ce que tu fais paraît correct et donc BO ne devrait pas renvoyer d'erreur. Il va donc falloir que tu détailles un peu.

Req1 : dimensions, informations, indicateurs
Req2 : dimensions, informations, indicateurs
Fusion : dimensions
Tableau : dimension, informations, indicateurs
indicateur : somme si alors / somme ... dans ...
etc etc

[Migraine]

J'ai actuellement 5 fournisseurs de données qui reprennent différentes informations, je vais essayer de vous synthétiser les choses au mieux...

Mon rapport est simple en soi, il n'y a qu'un tableau qui recoupe les informations des différents forunisseurs de données, je n'ai pas appliqué de section, mais une rupture sur les utilisateurs, et j'ai transformé la durée du stage (qui est une dimension) en INFORMATION lié à l'Id stage. (J'ai essayer de passer sans INFORMATION mais pas de changement, toujours #ERRI)

Et à part une rupture, je em suis contenté de filtré les valeurs nulls mettant en avant les données ou il y a des recoupements entre fournisseur (sauf pour les sessions cf voir plus bas)

Et pour la vue d'ensemble, un user peut avoir plusieurs stages, et les stages sont composé de plusieurs sessions, et pour chaque session, il y a une dimension (Etat user session) qui dit si le user etait présent ou non. Si ce dernier était présent, alors on renseigne la durée de la session, sinon non. Quoi qu'il arrive la Durée stage ets toujours renseignée. Et donc devrait me permettre de faire une somme par utilisateur et par stage...

FD1 :
Id stage (DIM pour DIMENSION) synchroniser FD2
ref stage (DIM) synchroniser FD2
Id user (DIM) synchroniser FD2
Durée stage (DIM)

FD2 :
Id user (DIM) synchroniser FD1
Id stage (DIM) synchroniser FD1
ref stage (DIM) synchroniser FD1
etat user session (DIM)
Num session (DIM)
Durée session (INDICATEUR)

Je sais que c'est aps forcément clair, mais je ne vois pas comment synthétiser plus que ça.

[Julien59]

Peux tu me dire de quoi est composé ton tableau ?
Tu parles de 5 fournisseurs de données, sont ils liés à FD1 et FD2 ?
Peux tu ne laisser que les objets :
Id user (DIM)
Id stage (DIM)
ref stage (DIM)
dans les 2 FD, ainsi que durée stage dans FD2
et nous dire ce qui est retourné dans un tableau?
Je parle bien de modification de requête, pas de modification de tableau.

[Migraine]

Tous mes fournisseurs (sauf les deux précédents) sont liés par l'Id user (info commune et fiable), les 3 autres fournisseurs permettant de récupérer des données divers, métiers (FD3), lieu de rattachement (FD4), et le dernier récupère le l'année de demande de stage (une date lié à l'utilisateur et au stage (L'id stage est synchroniser ici)) (FD5)

Le tableau se compose simplement en se basant sur les données du FD2, je récupère tel que toutes le dimensions et indicateurs de ce fournisseur, puis je rajoute les colonnes dont j'ai besoin en information dans le tableau, en filtrant les valeurs vides qui signifient l'absence de relation...


En faisant un petit test tel que tu me l'as demanddé... Trop fort, j'ai fait trés basique, mes données de Durée stage (la dimension changée EnNombre()) retourne des chiffres mais la sommes est en erreur, et en insérant l'information que j'ai faites à partir de cette donnée, la somme fonctionne... Hors c'est cette info qui ne fonctionne pas dans l'autre rapport...

J'ai du le facher un jour...

[Migraine]

Je me doute que mon sujet est hasardeux et très spécifique...

Cependant, je pense que dans ce forum (je n'ai rien trouvé pour le moment), il doit bien y avoir un sujet qui préconise certaines façon d'agir pour prévenir ce genre d'erreur ?

Alors si vous pouvez me mettre un lien, ce sera déjà ça !

merci d'avance,

[Julien59]

J'avais zappé ce sujet
Peux tu faire le test de faire ton tableau en supprimant tous les fournisseurs de données inutiles ?
Ne laisser plus que FD1 et FD2 en gros.
Les résultats sont ils corrects?

[Migraine]

Idem, l'erreur est toujours présente.

Mais en rebatissant les même fournisseurs dans un autre rapport... Ca fonctionne, alors que j'ai fait tout dans le même ordre.

Pas très logique... Ou du moins, je n'ai pas encore vu quelle logique suit BO dans ce cas précis.

[Julien59]

Ou alors tu n'as pas fait les mêmes étapes de la même façon...
Il suffit que tu aies mal lié une information sur ta dimension pour que BO renvoie une erreur.
Donc, maintenant, en refondant ta requête depuis le début, avec les 5 fournisseurs de données, ca fonctionne ?

[Migraine]

Pas d'erreurs sur la synchronisation de mes fournisseurs, c'est garantis !

Par contre, la ca va etre difficile de refaire tout ça pour moi, j'ai du passé à autre chose, reproduire le cas avec les 5 fournisseurs me prendrais trop de temps.

Mais j'ai finis par obtenir mon résultat, j'ai juste bidouillé un peu plus mon rapport en créant des variables intermédiaires... (Personnelement, Bo me décoit beaucoup à voir qu'on le berne avec des procédés pas logique du tout...)

Je deteste faire ça, mais j'ai pas vraiment eu le choix. Après l'important c'est que ça marche ! Sauf si mon client me demande pourquoi j'ai mis tant de variables... :/ Je risque de faire de la mauvaise pub à BO...

[Julien59]

Ce n'est pas BO qui aura de la mauvaise pub, mais toi
BO est stable et fait ce qu'on lui demande de faire. Si en recréant tes 2 requêtes, tu n'as plus la même erreur, c'est que tu n'as pas fait la même démarche des 2 côtés.
C'est en effet assez dangereux de bidouiller, même si des fois, on est un peu obligé de faire des usines à gaz au vue des demandes des clients.

N'oublie pas de cliquer sur si tu as trouvé une solution à ton problème.

Bon courage pour la suite

[Migraine]

Alors, je veux bien qu'on dise que je ne suis pas le roi de BO, mais je gére bien les interactions entre objets en prenant en compte bcp des fonctionnalités de l'outils (section, rupture, filtre, invites...).

Mais il y a des fois, depuis que je suis arrivé sur cette mission, ou BO ne se comporte vraiment pas de la même façon d'un rapport à l'autre...

Je prends en compte que je n'ai pas accès aux univers, ni à la base de données, que l'ensemble de ces deux éléments sont bourrés de problèmes (univers et base laissé à l'abandon pendant 5ans). Mais parfois, je vous assure, même pour des tests simples, je n'ai pas le même comportement d'un etat à l'autre en procédant de la même manière.

Bon, ça peut être causé par l'unviers ou la base, mais comme je n'ai pas vraiment d'élément pour vérifier cela, je me rabat sur reporter...

Et question bidouille... Je dois connaitre une 20aine de developpeur BO (experiences différentes), et tous me disent que parfois, BO fait n'importe quoi... :/

Après je le considère toujours comme un bon outils (par rapport aux autres...), mais ces dernières semaines, il me fait vivre un vrai passage à vide...

Sinon, pour en revenir au sujet, voici ma solution :

Si vous n'arrivez pas à obtenir votre résultat avec vos indicateurs/dimensions tel quel, alors faite une nouvelle approche pour obtenir le même résultat

[Julien59]

Alors, je veux bien qu'on dise que je ne suis pas le roi de BO, mais je gére bien les interactions entre objets en prenant en compte bcp des fonctionnalités de l'outils (section, rupture, filtre, invites...).

Je ne dis pas que tu ne maîtrises pas
Je te chariais un peu. Comme tout bon outil, BO a quelques failles, ca serait dommage qu'il n'en ait pas, comment le faire évoluer sinon...

Bon, ça peut être causé par l'unviers ou la base, mais comme je n'ai pas vraiment d'élément pour vérifier cela, je me rabat sur reporter...

Il est vrai que lorsqu'on se retrouve en tant que "simple" utilisateur, on se sent un peu démuni.. En tout cas, pour ma part... Ne pas pouvoir regarder le sql, ou toucher à l'univers, c'est assez dur...
Bon courage en tout cas !