Discussion :

[Liszt]

Bonjour à tous

Alors voilà, j'ai un ptit souci. Sur des rapports que je retravaille, j'utilise des requêtes SQL à la carte. Tout marche bien, c'est super. Par contre, dès que je fais quelque chose (comme changer l'ordre des prompts par exemple), les modifications "SQL à la carte" sont perdues, au profit du SQL généré automatiquement.

J'aimerais éviter ça, en particulier pour les utilisateurs qui pourraient "trifouiller" la query, dire que "ça ne marche plus", et en regardant le SQL, ne pas voir les modifs que j'ai faites (j'ai oublié de dire que le SQL automatique "écrase" le SQL à la carte).

Voilà, si vous avez des idées, j'suis preneuse !

Merci !

[HarryCoco]

Bonjour,

à ma connaissance ce n'est pas possible.
La seule solution consiste à interdire tes utilisateurs de modifier la requête.
Sinon, le mieux serait quand même de modifier l'univers pour intégrer tes modifs.

Bon courage.

[Bruno2r]

Bonjour,

à ma connaissance ce n'est pas possible.
La seule solution consiste à interdire tes utilisateurs de modifier la requête.
Sinon, le mieux serait quand même de modifier l'univers pour intégrer tes modifs.

Bon courage.

Entièrement d'accord avec HarryCoco.

Le sql à la carte présente un risque :

• modification par l'utilisateur
• modification du schéma de la base de données

Bien entendu, ce dernier point impacte également les univers, mais il est plus facile de corriger un univers, après rafraichissement de la structure, que de corriger une centaine de sql à la carte ...

Pour ma part, chaque fois que j'utilise un sql à la carte, je crée une vue Oracle dans ma base infocentre, qui interroge la (ou les) base(s) de production au travers de DBLinks.
En cas de changement dans le shéma, je ne corrige que les vues et cela impacte automatiquement tous les univers concernés et tous les documents BO correspondants.

Cela dit, pour en revenir au problème de Liszt, ce qu'elle fait n'est, à mes yeux, pas du SQL à la carte proprement dit mais de l'aménagement du SQL déterminé par l'univers.
Donc la solution me semble être la suivante :

1. mettre au point une fois pour toute le SQL
2. le sélectionner
3. le copier
4. l'utiliser dans une véritable requête en SQL à la carte
5. au travers d'une connexion sur la base (et non d'un univers)
6. Modifier les qualifications des champs numériques qui en SQL à la carte sont automatiquement qualifiés d'Indicateurs

[Liszt]

Mmmm je dois avouer, Bruno, que je n'ai pas vraiment compris ( ) ...

En fait, c'est un micro projet de plan de budget que je récupère. Je dois remettre à jour quelques requêtes pour répondre aux besoins spécifiques des users. Or, j'ai déjà changé une LOV dans l'univers pour répondre à leurs besoins qui étaient censés être simples.

Pour ce besoin spécifique, je ne vois pas comment modifier la requête (à part refaire tout le projet, mais bon, vu que c'est censé être une activité subsidiaire...)

• Le seul truc qui m'aurait bien aidée aurait été de faire un filtre "intelligent", directement dans le rapport, où je dirais que [Year]=découpage du mois sélectionné (il est sélectionné sous la forme "2007-01" par exemple. Un substr aurait été parfait). Or, ce n'est pas possible de faire un filtre évolué, à ma connaissance. Si vous connaissez un moyen, je suis preneuse.
  
• Une autre chose qui m'aurait bien aidée aurait été de le générer directement avec l'éditeur de query, mais BO ne propose pas des fonctions (ou alors je ne sais pas comment faire)
  
• La requête est faite d'une telle manière qu'il me faut rapatrier les données de toutes les années confondues. Ainsi, un objet créé dans l'univers (pour l'année) ne pourra pas m'aider, car il restreindrait mon cube, je pense, non ?

C'est pour cela que j'ai fait le SQL à la carte (chez moi, c'est dans la query, bouton SQL, "Custom SQL"), où je précise directement le substr du mois dans la requête.

Renseignements pris, mes users ont accès au "edit query" mais ne s'en servent pas. Il n'empêche que ce n'est pas propre du tout .

J'avoue que je ne suis pas du tout claire dans mes explications, et je vous prie de bien vouloir m'en excuser.

[Paci92]

Bon je dois avouer que je n'ai pas tout compris, mais j'ai accroché sur un truc : le filtre évolué impossible à faire ... j'imagine que tu es sous Webi donc ...

La solution que j'utilise personnellement pour remplacer les filtres évolués des rapports que je migre de 6.5 à XI R2, c'est la création d'un variable qui contient la formule de ton filtre "évolué", et qui te renvoie un booléen (1 ou 0 par exemple). Après, tu n'as plus qu'à faire porter le filtre sur le bloc ou le rapport sur le résultat de cette variable.

En espérant t'avoir aidé,

Bon courage

[Bruno2r]

Bon je dois avouer que je n'ai pas tout compris, mais j'ai accroché sur un truc : le filtre évolué impossible à faire ... j'imagine que tu es sous Webi donc ...

Liszt tu peux nous confirmer que tu es bien en Webi XiR2

[Liszt]

Bon je me suis craquée.

Oui je suis bien en WebI. Le problème est résolu. Mais il était plus compliqué que je ne pensais.

J'ai dû créer des objets dans l'univers reprenant mon SQL (avec un @Prompt en clause where). J'ai intégré cet objet dans l'éditeur de requête, en faisant un "= object". Ca marche bien, c'est propre, et le SQL généré automatiquement est identique à mon custom SQL.

Merci à vous tous. Merci Paci pour l'astuce, je suis sûre qu'elle me sera très utile plus tard