Discussion :

[Heremion]

Bonjour à toutes et à tous,

Je viens demander de l'aide ici car j'ai un petit souci aujourd'hui.

J'avais à l'origine une requête de ce genre :

Code sql :

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

1
2
3
select d.* 
from demande d
where d.id = :ID_DEMANDE

dans mon query et dont je renseignais le seul paramètre ID_DEMANDE en passant par le ParamValues.

Aujourd'hui, il y a un des champs du select que je veux voir à vide ou avec la valeur du champ initial en fonction d'une question posée à l'utilisateur.

Je m'explique.

Si je veux détailler le select, j'aurai :

Code sql :

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

1
2
3
select d.id, d.date_demande, d.montant, d.statut, d.supprime
from demande d
where d.id = :ID_DEMANDE

Si l'utilisateur dit qu'il ne veut pas voir le statut sur l'interface, j'aimerai pouvoir faire par exemple :

Dans le SQL :

Code sql :

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

1
2
3
select d.id, d.date_demande, d.montant, :STATUT as statut, d.supprime
from demande d
where d.id = :ID_DEMANDE

Dans le code Delphi :
- avoir dans le cas où je veux l'afficher ->

Code :

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

IBQDemande.Params.ParamValues['STATUT'] := 'd.statut'

- avoir dans le cas où je veux pas l'afficher ->

Code :

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

IBQDemande.Params.ParamValues['STATUT'] := 'NULL'

Le souci, c'est que tel quel, ça me retourne l'erreur :

"Le projet XXX a déclenché la classe d'exception EIBInterbaseError avec le message 'Dynamic SQL Error SQL error code = -804 Data Type unknown'.

Je pense que c'est parce qu'en insérant les valeurs de paramètres, je dois me retrouver avec le SQL suivant :

Code sql :

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

1
2
3
select d.id, d.date_demande, d.montant, 'd.statut' as statut, d.supprime
from demande d
where d.id = :ID_DEMANDE

et du coup il ne l'interprèterait pas.

Quelqu'un aurait une idée ?

Merci par avance

[Barbibulle]

Les IBX ne permettent pas ce genre de chose (une genre de macro pour créer la requête). Il existe des composants qui le font. Firedac il me semble...

Mais bon je ne procèderai pas comme ça....

J'utiliserai la requête complète et simplement j'utiliserai la propriété Visible du Field associé à statut ou la propriété Visible de la colonne de la grille....


Pour moi une requête ne s'occupe pas (ou très peu) de la présentation.... C'est à l'interface graphique de gérer ce genre de chose...

[skywaukers]

Bonjour,

je suis d'accord avec Barbibulle, une requette ne prend pas en considération les problèmes de présentation. Cependant, par soucis d'optimisation, il est quand même intéressant de pouvoir ne ramener que les colonnes qui sont nécessaires à ce qu'on veut faire. Je ne sais pas si ce que tu esaye de faire est possible, personnellement je procède différement. La propriété SQL de ton query est généralement un TStrings que tu peux renseigner ou modifier à l'exécution. Pourquoi ne pas mettre par exemple dans ton composant cette requette :

Code :

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

1
2
3
select {%champs%}
from demande d
where d.id = :ID_DEMANDE

puis lorsque l'utilisateur a choisi les champs qu'il veut afficher, tu construit la liste dans une chaine de caractères et tu remplace {%champs%} par cette chaine avant d'activer le query.

@++
Dany

[donnadieujulien]

A force de fournir des outils et/ou des objets de plus en plus complexe pour faire des choses simples les développeurs (en herbe) en oublient même l'essentiel, une requête SQL c'est d'abord une chaine de caractère.
Dans ce cas la avec un peu de réflexion et des outils simples comme strreplace on peut tout faire, sous réserve de trouver ou se cache la chaine de caractère.

En tout cas je suis vraiment opposé à ce genre d'objets qui ne servent franchement pas à grand chose...

[Barbibulle]

En tout cas je suis vraiment opposé à ce genre d'objets qui ne servent franchement pas à grand chose...

C'est certain c'est comme programmer en pascal, il ne faut pas oublier qu'après compilation c'est du code machine. Autant apprendre et programmer directement en code machine (allez... l'assembleur pour être plus tolérant...). (désolé, c'est un peu exagéré, c'est la proximité de Marseille qui déteint sur moi )

Moi je trouve au contraire que de ne pas utiliser ces objets Fields / Paramètres c'est passer à coté de choses intéressantes.

Si vous utilisez un type TxxQUERY, que vous fassiez votre requête dynamiquement lors de l’exécution ou lors de la conception, les objets FIELDS seront créés. (Donc autant en profiter...)
Qu'apporte les fields ?
L'utilisation plus simple des données comme les dates (s'affranchir du paramétrage régional du poste), les blobs, les champs calculés,
Les évènements au niveau field peuvent être intéressant comme le onValidate,
La définition du "display label"
Les règles de visibilité ou le readonly
Le formatage de la valeur à l'écran,
Un masque de saisie,
Un code source plus lisible,
Bien entendu il faut les utiliser avec des composants d'affichage de type TDBxxx.

Bref dire que cela n'apporte rien c'est passer à coté de pas mal de fonctionnalités.

Générer une requête dynamique c'est prendre le risque d'engendrer une requête qui est fausse, ou non optimisée, et je trouve aussi plus difficile la maintenance de ces requêtes et surtout la lisibilité du code.

Bref pour ma part je ne reviendrais pas aux requêtes dynamiques sauf cas bien particuliers.

[Heremion]

Bonjour à tous,

Tout d'abord, merci pour toutes vos réponses...

Finalement, j'ai opté pour laisser un SELECT * FROM DEMANDE et finalement modifier l'interface.
Au final, le contenu de cette requête était affiché dans un QReport. J'ai donc réadapté mon report pour cacher les champs que je ne voulais pas voir apparaitre.

Mais disons que le sujet méritait tout de même d'être abordé,... une requête dynamique, bien que ce ne soit pas préconisé, peut être utile...