[BO Xi R2] Fournisseur de données [Résolu]

[ghostlord79]

Bonjour,

Mon problème est le suivant : les utilsateurs de l'univers BO utilisent souvent des fichiers afin de travailler sur une population donnée. Ces fichiers ne sont jamais les mêmes, il est donc impossible de créer une table temporaire poru insérer les données et travailler sur la table.

Ces fichiers pouvant contenir plusieurs centaines de milliers de lignes, comment faire pour requêter avec BO sachant que je ne peux pas mettre plus de 1000 valeurs dans un in sous oracle (sinon la base me retourne un message d'erreur)?

Merci d'avance,

Guillaume

[jibjib]

tes utilisateurs n'ont pas accès à l'univers?

[ghostlord79]

non ils n'onty que le droit de requêter.

En fait il s'agit d'une migration de cognos impromptu v6(sur base DB2) vers BO Xi R2(sur base oracle 9i) et sous cognos ils pouvaient indiquer un fichier dans lequel aller chercher les données sans ocntrainte du nombre de lignes.

Ils ont besoin de cette fonctionnalité et pour l'instant je sèche un peu

[jibjib]

tu as essayé dans deski :
Données -> créer un fournisseur de données... -> accéder aux nouvelles données par un autre moyen -> fichier de données personnelles
et tu choisis ton fichier dbase

?

[schkrumble]

Quand tu dis "fichier", tu pense à des tables Excel ?
Si c'est le cas, qu'est-ce qui empèche les utilisateur de requêter directement sur leurs fichiers à partir de DeskIntelligence ?
[Edit : j'avais pas vu le dernier post de jibjib]

[ghostlord79]

Oui j'ai testé la méthode de jibjib.

j'ai créé un fournisseur de données en précisant qu'il pointe sur un fichier plat.

le problème, c'est lorsque je pose un condition dans la requête en excluant les lignes lorsque la valeur de tel champ est "Dans la liste" des valeurs de mon fichier plat (fournisseur de données), et bien j'ai le message d'erreur suivant :

"nombre de valeurs de doit pas dépasser 1000" (un truc du style)

c'est une limite oracle mais je ne parviens pas à contourner ce pb sous BO

[jibjib]

arf, je me disais bien aussi que tu avais essayé...
et bien vu que je n'utilise pas oracle, et que je suis pas un colosse dans le domaine, j'en ai aucune idée!
sorry et bon courage

[schkrumble]

Envoyé par ghostlord79

le problème, c'est lorsque je pose un condition dans la requête en excluant les lignes lorsque la valeur de tel champ est "Dans la liste" des valeurs de mon fichier plat (fournisseur de données)

je ne suis pas sûr de bien comprendre la façon dont tu t'y prends pour poser cette condition mais pourquoi ne pas remplacer cette condition dans la requête par un filtre directement dans le rapport ?

[jibjib]

Envoyé par schkrumble

je ne suis pas sûr de bien comprendre la façon dont tu t'y prends pour poser cette condition mais pourquoi ne pas remplacer cette condition dans la requête par un filtre directement dans le rapport ?

lol, c'est vrai que j'ai pas bien saisi non plus...

[ghostlord79]

voici la requête en PJ :

editeur_de_requete.JPG

La ligne ID MERCURE Pas dans Liste des résultats de la requête (' DP 2....), correspond à exclure les données issues d'un fichier, et ce fichier peut contenir plusieurs centaines de milleirs de lignes.

Là est-le problème car je dois seulement mettre 1000 valeurs dans le fichier sinon j'ai un message d'erreur.

Suis-je plus clair?

[Bruno2r]

Bonjour,
Il est clair que en SQL Oracle IN ou NOT IN sont utilisables avec un nombre de valeurs raisonnables et que dans dans ton cas les 100 000 sont un peu difficiles à digérer .

En SQL toujours, si on avait à exclure ces nombreuses valeurs, on préfèrerait les avoir dans une table A_EXCLURE (ou comme résultat d'un Select) et on utiliserait alors :

Code :

1
2
3
4
5
SELECT ID_MERCURE, TELDOM, TELPRO, TELPORT, DATENAISS, AGE
FROM TABLENOM A
WHERE NOT EXISTS 
(SELECT 1 FROM A_EXCLURE B
WHERE A.ID_MERCURE = B.ID_MERCURE)

Le problème dans BO c'est qu'on peut faire des requêtes Union, Minus ou Intersect portant sur les mêmes objets (donc même select) mais seul le SQL à la carte permet autant de souplesse.

Problème supplémentaire : tes données sont dans une feuille Excel .
Enfin bref ! La seule piste que je puisse te suggérer c'est de

1. synchroniser tes deux sources en liant le ID_MERCURE des 2 sources.
2. mettre en section ID_MERCURE
3. utiliser l'affichage conditionnel de la section en fonction d'un indicateur de la feuille excel (si celui ci est null c'est que ID_MERCURE n'est pas dans la feuille excel donc on l'affiche)

Je ne promets rien ce n'est qu'une piste.
La vrai solution serait que l'utilisateur laisse tomber Excel pour Access ou bien que ses listes soient intégrées dans Oracle.

Je signale quand même au passage que si l'on exporte les données d'une requête (même basée sur une feuille Excel) en choisissant l'option vers un SGBD (que ce soit Access ou Oracle) la table est immédiatement créée dans celui ci sous le nom du fournisseur de données (d'où l'impérieuse nécessité de renommer celle ci d'un nom unique compatible avec le nommage des tables).

[ghostlord79]

J’ai déjà testé la « synchonisation des deux sources en liant le ID_MERCURE des deux sources ».

Le problème, c’est que ça provoque une sorte de jointure interne (et non externe). En mettant les deux objets (ID_MERCURE) dans un même bloc, le rapport n’affiche alors que les ID_MERCURE communs aux deux fournisseurs de données. Je perd alors toutes les lignes qui m’intéressent

[schkrumble]

Je viens de tester une solution proche de celle de Bruno2r avec le filtre dans le rapport et qui, chez moi, marche :

Il faut que ta table Excel des lignes "à exclure" ait au moins 2 champs, l'identifiant (ID_MERCURE dans ton cas) et un second qui n'a aucune valeur vide.

Tu crée ta première requête avec l'univers
Tu crée une deuxième source de donnée basée sur ton fichier Excel "à exclure".
Tu lie ID_MERCURE de tes deux sources
Tu spécifie le deuxième champs comme une information rattachée à ID_MERCURE.
Tu pose un filtre dans le rapport sur ce deuxième champs en n'acceptant que la valeurs #EMPTY (inutile d'insérer une rupture).

Si ca marche chez moi, ca devrait marcher pour toi...

[ghostlord79]

ok je tente et je vous dit

merci

[ghostlord79]

Apparemment ça ne marche pas chez moi :

Je crée la première requête avec l'univers. Le résultat est, par exemple, les quatres lignes suivantes :

IDMERCURE
A
B
C
D


Je crée une deuxième source de donnée basée sur ton fichier Excel "à exclure". Il contient par exemple :

IDEXCL INFO
B x
C x


Je lie ID_MERCURE de tes deux sources
Je spécifie le deuxième champs comme une information rattachée à ID_MERCURE : c’est ma colonne « INFO » qui contient les valeurs « x ».

A ce point du process, si je met les deux ID dans un même tableau, j’obtiens ça :

IDMERCURE IDEXCL

A A
B B
C C
D D


Je pose un filtre dans le rapport sur le champ « INFO » en n'acceptant que la valeurs #EMPTY


Mon tableau se vide de tous ses résultats :

IDMERCURE IDEXCL




Finalement, dès lors que j’ai lié mes deux dimensions, c’est comme si les deux fournisseurs étaient fusionnés. C’est comme si la valeur x était attribuée à toutes les lignes de mon tableau.

[Bruno2r]

Bonjour,
Si je préconisais de mettre IDMERCURE, une fois lié, en section c'était pas forcément pour mettre les infos des deux fournisseurs de données dans le même tableau.
C'était plutôt pour positionner les données des deux sources dans deux tableaux côte à côte.
Pourquoi ? :
Vouloir obtenir un seul tableau sous entends que toutes les dimensions soient liées entre elles.
Positionner dans la même section deux tableaux affiche le ou les tableaux qui existent pour chaque valeur de cette section.
Alors je me dit qu'il doit y avoir moyen dans Format de Section de masquer l'affichage de la section lorsque les données d'Excel existent.
Ce qui devrait produire le résultat attendu.

[ghostlord79]

en fait c'était le fichier source qui était pas bon. L'ID MERCURE était en numérique alors que cet un vachar en base.

Merci beaucoup pour cette solution.

[Bruno2r]

Envoyé par ghostlord79

en fait c'était le fichier source qui était pas bon. L'ID MERCURE était en numérique alors que cet un vachar en base.

Merci beaucoup pour cette solution.

Çà c'est le coup classique !
J'aurais dû penser à te le dire .
Enfin content que tu y sois parvenu.