Visualiser l'odre du tri de votre collation SQL Server

Petite astuce pour trouver le caractère suivant le "z" lors d'un tri sur votre base de données.
Cela peut s'avérer utile si vous souhaitez avoir un membre qui apparaisse toujours en dernier lorsque vous classez les membres d'une table par ordre alphabétique (sans la nécessité d'une colonne supplémentaire de tri).
Pour retrouver le classement des caractères sur votre base, utilisez la requête suivante:

CREATE TABLE T1 ( ID int, CARACTERE AS char(ID))

DECLARE @I AS Int
SET @I=1

WHILE (@I <256)
BEGIN
INSERT INTO T1(ID) VALUES (@I)
SET @I = @I+1
END

SELECT * FROM T1 ORDER BY CARACTERE go

DROP TABLE T1

Réponse (sur une base en SQL_Latin1_General_CP1_CS_AS): Il existe donc 4 caractères étant classés après le "z" dans un tri. Dans l'ordre: Ð, ð, Þ et þ.

Bien sûr, cela dépend de la collation définie sur votre base. Par exemple la même requête en French_CI_AS donnera le résultat suivant: Ž et ž

Pour information, Ð, ð, Þ et þ sont des lettres utilisées dans l'alphabet islandais...j'aurais pu les chercher longtemps sans cette requête!

SSIS 2008 a fait le ménage

Petite surprise en appliquant à une base SQL Server 2008 un script créé en 2005 et qui manipulait les vues et fonctions systeme sysdtspackagefolders90, sysdtspackages90, sp_dts_deletepackage, sp_dts_deletefolder et autres... Celles ci n'existent plus en 2008! Pour être plus exact, elles ont été renommées. Microsoft a en effet fait du ménage dans ces labels qui faisaient référence à la version 2000 de l'ETL (DTS). Vous utiliserez donc désormais les vues et fonctions systeme sysssipackages, sysssispackagefolders, sp_ssis_deletefolder, sp_ssis_deletepackage etc.

Financial Planning Accelerator

Une annonce parue aujourd'hui sur le site Partners de Microsoft et commentée sur le très bon blog de Chriss Webb: PerformancePoint Planning est de retour dans une version quasi open-source!

Finalement, Microsoft a entendu les appels de ses partenaires (cf post du mois de fevrier) et permet donc de reprendre le projet planning et d'y apporter sa touche personnelle. Les utilisateurs eux, pourrons bénéficier de ce produit via la licence Sharepoint qui donne accès par la même occasion à PerformancePoint Services Monitoring & Analytics (ex Proclarity).

Kimball Slowly Changing Dimension (SCD)

L'une des composantes d'un projet BI est la gestion de ce qu'on appelle les "Slowly Changing Dimension" (SCD) ou "dimensions à variation lente". L'enjeu est le suivant, historiser ou non les attributs d'une dimension et si oui, dans quelle mesure. Il existe plusieurs types de SCD, numérotés de 0 à 6, chacun permettant de couvrir un cas de figure particulier, les plus couramment utilisés étant les types 1 et 2.

Prenons l'exemple d'une dimension employé, chaque employé occupant un poste précis. Une SCD de type 1 ne garderait dans le datawarehouse que le dernier poste occupé par un employé. Une SCD de type 2 permettrait elle de garder un historique des postes occupés par l'employé, en précisant les dates de début et de fin de chacun de ces postes.

Il existe différentes méthodes pour appliquer ces principes dans un lot de chargement Integration Services, que ce soit à l'aide de composants de recherche (lookup) ou du composant SSIS SCD. Il existe cependant une alternative gratuite et performante: Le Kimball Slowly Changing Dimension component. Ce composant développé par Todd McDermid et disponible gratuitement sur CodePlex permet de gérer très facilement le chargement des SCD de type 1 et 2.

Seul petit bémol, l'impossibilité de transférer des champs techniques or audit... ce qui n'est pas nécessairement bloquant.

Si vous souhaitez l'essayer, la version 1.4 est disponible ici, je vous le conseille vivement!

Sum Distinct avec SSRS

Reporting Services (SSRS) 2005 propose de nombreuses fonctions d'agrégation dont Sum, Min, Max, Avg, Count, Count distinct etc.

Malheureusement il arrive souvent qu'on ait besoin d'une autre fonction qui n'est pas fournie par défaut: Sum Distinct. Ce billet vous montre donc comment l'implémenter dans votre rapport.

Imaginons qu'on ait une requête qui ramène une liste combinant des employés, leurs spécialités, leur département et leur salaire. On aura donc une spécialité d'employé par ligne et donc potentiellement plusieurs lignes pour un même employé.

Si on désire réaliser un rapport avec un regroupement par département affichant le nombre d'employés à ce niveau agrégé, alors on peut utiliser la fonction CountDistinct(Fields!EmployeeID.value) dans la case correspondante, ce qui ramène le bon résultat.

Le problème apparaît lorsqu'on désire par exemple calculer la somme des salaires d'un département. On pourrait rajouter un champ dans la requête qui serait le résultat d'une sous requête et ramènerait le TotalSalaireDepartement pour chaque département. C'est une solution qui est peu envisageable si le nombre de champs à rajouter est élevé. D'où l'idée de cette fonction SumDistinct qui permet de récupérer le résultat grâce à un petit bout de code Vb.

Pour ajouter la nouvelle fonction, aller dans l'onglet "code" des propriétés du rapport:

Il ne reste plus qu'à appeler la fonction dans les cases du rapport.

SumDistinct(Mesure, ID, Valeur)

Ce qui donne pour cette exemple au niveau d'une ligne département:

=Sum(Code.SumDistinct(01, Fields!EmployeeId.Value, Fields!Salaire.Value))

Remarquez dans le code la clé de la HashTable qui est composée d'une Mesure (01 pour Salaire) et d'un ID (EmployeeID). Cette astuce permet de pouvoir réutiliser la même fonction pour des mesures différentes, par exemple 01 pour le salaire, 02 pour le poids de l'employé ou encore 03 pour l'âge de l'employé, sous réserve que les valeurs agrégées au niveau département de ces dernières mesures aient un intérêt quelconque:)

Installer Reporting Services sur Windows Server Web Edition

Voici un problème auquel j'ai été confronté récemment chez un client, installer Reporting Services sur une Web edition de Windows server.

Si vous lancez la procédure classique d'installation SQL Server, vous réaliserez vite que le nombre de possibilités est assez limité. Vous ne pouvez en effet qu'installer les outils clients sur cette version de Windows Server (les autres composants étant grisés). Il est en effet impossible d'installer un moteur de base de données sur cette édition. Cela dit, dans mon cas, le but était seulement d'installer la partie applicative de Reporting Services, les bases de métadata étant stockées sur un autre serveur dédié aux bases de données.

La bonne nouvelle est qu'il est possible d'installer Reporting Services même si le wizzard classique d'installation ne le permet pas. L'astuce est la suivante: lancer le fichier "SqlRun_RS.msi" qui est situé dans le répertoire "\Servers\Setup" du CD SQL Server 2005.

Une fois l'installation terminée, vous pouvez configurer votre serveur de rapport en lançant "Reporting Services Configuration". C'est à travers cette interface que vous chosirez par exemple le serveur qui accueillera vos bases métadata "ReportServer" et "ReportServerTempDB".

Le code de Planning bientôt sur codeplex?

Comme je vous l'annonçais dans mon précédent billet, Microsoft n'exclut pas la possibilité de mettre le code de PerformancePoint Planning à disposition sur Codeplex.
C'est pour l'instant une idée parmi d'autres, qui ne serait mise en oeuvre qu'après la sortie du SP3 en milieu d'année.

J'en ai discuté avec différentes personnes et j'ai eu des retours assez variés. Certains y voient la possibilité de faire évoluer l'application et de continuer à la proposer à des clients pour des problématiques de writeback via Excel avec workflow, d'autres sont pour...au cas où..., d'autres encore préfèrent passer à autre chose. D'où l'idée de lancer ce petit sondage pour savoir ce que vous en pensez. Celui ci est disponible sur la droite de cet écran.

Les réponses disponibles sont les suivantes: (Update: Résultats)

• C'est une super nouvelle, j'attends ça avec impatience: 44%
• Pourquoi pas, ça peut toujours être utile...un jour: 44%
• C'est pas la peine, je préfère oublier planning: 12%

Bon vote!