J'ai été confronté ce matin à un problème sur l'éditeur de transformation « Recherche ».

En effet pour un de nos clients nous récupérons, sur plusieurs bases ACCESS crées par le logiciel de comptabilité « QUADRA », l'ensemble des données comptables que nous réinjectons toutes les nuits dans un DataWarehouse. Pour ce faire nous récupérons la liste des comptes de toutes les bases, que nous insérons dans une table commune « PlanComptable » du DataWarehouse, en testant si le compte n'existe pas déjà. Nous avons une clé primaire sur le numéro de compte.

Voici le schéma SSIS en image qui vaut mieux que 3heures de discours !

Seulement voilà, malgré une conception optimale(Et oui parfois faut bien s'envoyer des roses!), on peut rencontrer un problème du genre « Violation de clé primaire » lors de l'insertion des données.

En effet, lorsque l'on a sur une base un numéro de compte = 'AAEEEEAA' (inséré dans le DataWarehouse) et sur une autre base le compte = 'AaeeeeAA', et bien, oh la mauvaise blague!! Le lookup les considère différents alors que SQL SERVER les considère identiques. D'où la fameuse Violation de clé primaire !!

Plusieurs solutions se présentent à nous, soit on passe tous les numéros de comptes entièrement en majuscules ou entièrement en minuscules dans la requête directement, soit dans le paquet par le biais d'une colonne dérivée. 

Solution 1 :

select UCASE(Numero) as Numero, Type, Intitule from Compte

UCASE(ACCESS) est l'équivalent de UPPER en SQL SERVER

Solution 2 :

Il existe 2 méthodes pour planifier l'exécution d'un paquet SSIS:

1. Par le biais du serveur Intégration Services dans le répertoire MSDB.

2. Par le biais du système de fichiers

METHODE 1

Depuis Visual Studio 2005 ou 2008, sur le paquet SSIS, faire Fichier/Enregistrer une copie de « Nom du Paquet SSIS » en tant que... Puis renseigner: l'emplacement du package(dans notre cas Magasin de packages SSIS), le serveur(ici le serveur local) et le chemin d'accès au package « /MSDB/Nom du Package » :

Nom de l'étape : Mettre un nom évocateur,

Type: Dans notre cas mettre « Package SQL Server Integration Services »

Exécuter en tant que : Compte de service SQL Agent

Dans l'onglet Planification, vous pouvez planifier l'exécution journalière, hebdomadaire ou mensuelle sur les horaires et les dates voulues.

METHODE 2

Cette méthode ne nécessite pas l'enregistrement du paquet SSIS sur le serveur d'Intégration Services! Lors, de la création de l'étape du job, vous pouvez sélectionner dans source du package : Système de fichiers comme suit:

Quelle utilité me direz-vous?

Nous nous sommes posé la question lorsqu'un de nos clients a voulu lancer des mises à jour du DataWarehouse selon son grès. En effet, le client avait notamment besoin lors des périodes comptables, de faire de fréquentes mises à jour du DataWarehouse depuis ses bases SAP, afin d'intégrer les nouvelles écritures.

La solution dans notre cas, présentée ci-dessous, est envisageable car le remplissage SSIS du DataWarehouse est de très courte durée(de l'ordre de la minute). Les bases de données sources SAP et celles du Datawarehouse sont peu sollicitées, l'utilisateur lambda n'y voit que du feu. 

Fini les nombreux appels téléphoniques, afin de mettre à jour le DataWarehouse!

Première étape, il faut créer un job sur SQL SERVER afin de planifier le lancement du paquet SSIS de remplissage du DataWarehouse. Je ne m'étendrai pas sur la création d'un job exécutant un paquet SSIS qui fait l'objet d'un autre billet.

Une fois le job créé, que je nommerai dans notre exemple «DWRemplissage FR», je développe une procédure stockée sur le DataWarehouse, ici nommée «Update_bdd_reporting_FR», qui fait appel à ce job comme suit:

Maintenant la dernière étape consiste à créer un report qui, au niveau des données, appelle la procédure stockée «Update_bdd_reporting_FR» précédemment créée, puis de publier le report sur le portail web.

Il faut bien sûr restreindre l'accès à ce report, aux personnes susceptibles de lancer la procédure stockée.

C'est tout pour aujourd'hui!

Pour un tableau simple sans regroupements, c est très simple, il suffit de sélectionner la ligne de détail du tableau, et mettre dans la propriété BackgroudColor le code suivant:

=iif(RowNumber(Nothing) mod 2, « couleur1 », « couleur2 » )

Le résultat en image:

Sur ce billet, je vais vous présenter l'outil « Reporting Services Scripter », développé en .NET Windows Forms, qui permet entre autre de récupérer tous les fichiers .rdl, les sources de données et les rôles d'un serveur de reports. Il permet aussi de les déployer sur un autre serveur. 

Cet outil, développé par Jasper Smith, est compatible SQL SERVER 2000, 2005,2008, sur les plateformes Windows 2000, XP, Vista, Windows Server 2003 et 2008. Le programme nécessite l'installation du framework .NET 1.1.

Fini la perte de temps, à déployer un par un les reports et à rattacher la bonne source de données sur chacun d'entre eux. Une fois l'archive décompressée, éditer le fichier servers.xml, et ajouter l'url du webservice du serveur de reports source et du serveur de destination comme suit: 

Sauvegarder et fermer le fichier de configuration XML.

Lancer l'application RSScripter.exe, cliquer sur le bouton OPTIONS, dans l'onglet GLOBAL sélectionner « Sript Only » (pour récupérer les fichiers en local) ou « Script and Transfer » (pour récupérer les fichiers d'un serveur et les transférer sur un autre).  

Sélectionner le répertoire de destination dans Output en bas de la fenêtre.

Sélectionner le serveur de rapport source et cliquer sur le bouton Get Catalog.

Choisir les éléments à récupérer, ici j'ai des fichiers .rdl, une source de données et les roles du serveur de report puis cliquer sur le bouton Script. Et voilà, en quelques clics, on peut récupérer l'ensemble des reports d'un serveur.

Dans le cas où vous transférez les reports vers un serveur de destination, il est conseillé de faire une sauvegarde des bases de données ReportServer et ReportServerTempDb.

Pour de plus amples informations je vous invite à visiter le site du développeur :

http://www.sqldbatips.com/showarticle.asp?ID=62

Il peut arriver que lors de l'export Excel d'un report, on ait des colonnes supplémentaires « parasites », ceci est dû à la position d'une zone de texte qui fait office de titre au dessus du tableau comme le montre l'image suivante:

Pour éviter ce problème, il faut ajouter une ligne d'entête au tableau et fusionner les cellules comme suit:   

Et voici le résultat en image, terminé les colonnes parasites!