Paramétrage efficace des dates

prédéfinies, telles
que DATEPART() et DATENAME (), constitue la meilleure
méthode de formatage des champs datetime. Et dans le
cadre de Reporting Services, vous pouvez incorporer ces
fonctions prédéfinies dans la requête source pour un rapport
ou une expression, de sorte que les dates seront préformatées.
Dans l’un des rapports que je devais réécrire, je devais
être en mesure d’utiliser un champ datetime, à  savoir le
champ DueDate (date d’échéance) de la table SalesOrder-
Header, en tant que champ renvoyé dans le jeu de données
de rapport original et en tant que paramètre afin de restreindre
l’étendue du rapport à  une plage de
dates sélectionnée par l’utilisateur. La première
étape du paramétrage du champ
DueDate a consisté à  l’ajouter au jeu de données
original. Le listing Web 1, téléchargeable
à  l’adresse http:// www.itpro.fr (Club abonnés),
illustre la requête modifiée pour le rapport
Territory Sales Drilldown Parameters
que nous avons utilisé, lequel inclut désormais
le champ Group de l’exemple précédent
et le nouveau champ formaté DueDate. Ensuite, pour limiter
les données sur le rapport à  la valeur sélectionnée dans la
liste déroulante de paramètre, vous devez combiner le paramètre
DueDate avec une expression de filtre. J’ai dû relever
quelques défis lorsque j’ai ajouté la logique afin de remplir le
menu déroulant de paramètre DueDate et appliquer le filtre.
Premièrement, dès qu’un paramètre utilise un jeu de données
pour remplir un menu déroulant, même si les valeurs
null sont autorisées, Reporting Services ne les génère pas automatiquement.
Deuxièmement, les expressions de filtre ne
peuvent comparer que des valeurs du même type de données,
de sorte que le type de données des deux sources doit
correspondre. Je vais expliquer l’importance de ces facteurs
dans un instant.
Pour paramétrer le champ DueDate, accédez à  l’onglet
Data du rapport Territory Sales Drilldown Parameters et
créez un autre jeu de données intitulé DueDate_DropDown.
Ce jeu de données va remplir la liste déroulante de paramètre
DueDate. Le listing Web 2 illustre le code servant à 
générer le jeu de données DueDate_DropDown. Remarquez
que Visual Studio .NET contient deux outils de génération
de requêtes pour Reporting Services : le concepteur de
requêtes générique (Generic Query Designer) et le concepteur
de requêtes graphique (Graphical Query Designer). La
principale différence entre les deux est que le deuxième,
dont je recommande l’utilisation, permet de créer graphiquement
une requête SQL en sélectionnant les tables et les
champs que vous souhaitez inclure. Ces deux concepteurs
de requêtes disposent d’un volet SQL dans lequel les utilisateurs
peuvent entrer ou coller directement la requête.
Comme le montre le listing Web 2, j’ai utilisé une combinaison
des fonctions CAST() et DATEPART() pour concaténer
l’année et le trimestre du champ DueDate (par ex., pour
afficher le troisième trimestre de 2002 sous la forme 2002-3).
Le recours à  la clause UNION afin de sélectionner une valeur
null pour DueDate est important si vous devez renvoyer une
valeur null à  la liste du paramètre (par ex., si les utilisateurs
n’ont pas sélectionné une période spécifique). Sans la clause
UNION, les utilisateurs devraient sélectionner une période
spécifique, telle que 2002-3, au lieu d’être capables de voir
les enregistrements pour toutes les dates d’échéance.
L’étape suivante consiste à  créer le paramètre DueDate
avec un type de données String et à  définir ses valeurs disponibles
de telle sorte qu’elles proviennent du jeu de données
DueDate_DropDown que vous venez de créer, en sélectionnant
DueDate en tant que champ Value et champ
Label. Comme dans l’exemple précédent, vous créez le paramètre
dans la boîte de dialogue des propriétés Report
Parameters. Vous sélectionnez ensuite l’option Allow Null value
et vous définissez la valeur non interrogée par défaut à 
=Nothing, qui est équivalente à  null et forcera le rapport
rendu à  afficher les enregistrements pour toutes les dates
d’échéance.
La figure 5 illustre le menu déroulant Due Date. Néanmoins,
vous n’avez pas encore ajouté l’expression de filtre,
de sorte que la sélection d’une date d’échéance n’affectera
pas le contenu du rapport. Dans Reporting Services, vous
pouvez appliquer un filtre à  n’importe quelle région de données
basée sur une expression. Par exemple, il est possible
d’appliquer une expression de filtre aux propriétés de la
seule table du rapport, SalesTable, ce qui constitue l’étape
suivante. Vous accédez de nouveau aux propriétés de la table
en cliquant avec le bouton droit de la souris sur la section
dans l’angle supérieur gauche de la table et en sélectionnant Properties. Ensuite, sélectionnez l’onglet
Filter et entrez l’expression de
filtre sous la forme
:

=IIF(Parameters!DueDate.Value is
Nothing, « All »,
Parameters!DueDate.Value)

=

=IIF(Parameters!DueDate.Value is
Nothing, « All »,
Fields!DueDate.Value)

Dans ces expressions, lorsque la
valeur de FilterExpression est égale à  la
valeur de FilterValue, Reporting Services
applique le filtre au rapport et exclut
les données qui ne correspondent
pas à  l’évaluation du filtre. Dans
l’exemple DueDate, lorsque le paramètre
DueDate est NULL, le rapport affiche
tous les enregistrements. Si le paramètre
a une valeur telle que 2002-3,
l’utilisateur verra uniquement les enregistrements
du rapport qui ont pour
valeur de champ DueDate 2002-3.
Notez que vous devez vous assurer que
le jeu de données DueDate_Drop-
Down contient une valeur de type de
données String pour le champ
DueDate, de sorte que ce dernier corresponde
au type de données du
champ DueDate ajouté au jeu de données
TerritorySales original. Comme
vous avez employé un type de données
String pour les champs DueDate, vous
pouvez ajouter le littéral de chaîne « All »
dans l’évaluation de l’instruction de
filtre afin de correspondre à  tous les
enregistrements. Logiquement, le
filtre sera évalué à  All=All et tous les
enregistrements s’afficheront dans le
rapport. Le fait d’employer « All »
comme littéral de chaîne est arbitraire
et tout autre littéral de chaîne fonctionnerait
dans ce cas de figure, que ce
soit « Everything » ou « AllData », voire
« Banana ».
Pour montrer aux utilisateurs la
période de temps qu’ils visualisent,
vous pouvez ajouter dans la section
du titre du rapport une zone de texte
intitulée Date Order Due (date
d’échéance de la commande), ayant
l’expression suivante :

=IIF(Parameters!DueDate.Value is
Nothing, « All Dates »,
Fields!DueDate.Value)

Si NULL est sélectionnée, ce qui est le cas par défaut, les
utilisateurs verront All Dates (toutes les dates) comme titre
du rapport ; sinon, ils verront la date qu’ils ont sélectionnée
(par ex., 2002-3), comme l’illustre la figure 5.
La frontière devient floue entre le rôle du DBA et celui du
développeur. Même les outils de gestion mettent toujours
plus l’accent sur l’aspect développement. Heureusement,
Microsoft nous aide à  effectuer cette évolution progressivement.
Dans Reporting Services, vous utilisez des paramètres
et des expressions afin de développer une logique relativement
complexe dans les limites de l’environnement de génération
de rapports, sans avoir à  écrire du code complexe.
Les paramètres et les expressions sont des fonctionnalités
puissantes, qui vous permettent de donner libre court à 
votre imagination à  mesure que vous développez des fonctions
précieuses dans vos rapports. Et si vous pensez que
vous avez été au bout des possibilités offertes par les
paramètres et les expressions, vous pouvez passer à  la puissance
véritable de l’écriture de code .NET car Reporting
Services prend largement en charge les assemblys personnalisés.
C’est une voie sur laquelle j’ai commencé à  m’engager.