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! 

En migrant un package SSIS d'un serveur 32 bits vers un serveur 64 bits vous vous rendrez très vite compte, si celui-ci se connecte à une "base de données" Access qu'il y a un p'ti problème. 

En effet, par défaut un package SSIS est paramétré pour s'exécuter dans le runtime 64 bits. Là où ça bloque, c'est que les drivers permettant la connexion à la base de données Access, les fameux Microsoft Jet 4 ne sont pas compatible pour l'environnement 64 bits...

Heureusement, il est possible de forcer SSIS à exécuter le package dans l'environnement de runtime 32bits. Pour se faire, il suffit dans les propriétés du projet de Business Intelligence de Visual Studio de mettre "False" dans le paramètre "Run64BitRuntime"

Voilà c'est tout! Mais cela permet d'exécuter le package en débuggage dans Visual Studio... pour l'exécution via un job schedulé c'est une autre histoire! 

En fait, pour simplifier, SQLServer fait appel au composant DTExec pour l'exécution des packages SSIS auquel il faut passer les paramètres tels que "/SQL "\PackageName" /SERVER "." /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING E". Pour les systèmes 64 bits, l'exe se trouve dans le répertoire "<Disque système>:\Program Files\Microsoft SQL Server\100\DTS\Binn". Dans notre cas, pour exécuter le package dans de bonne condition, il faut faire appel à l'exécutable spécifique de la version 32 bits se trouvant dans le répertoire suivant :"<Disque système>:\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn".

Bien entendu il est possible de lancer le package via notre job schedulé... Le pire c'est que c'est assez simple... Dans la fenêtre de paramétrage de l'exécution du package, il suffit d'éditer la chaîne de paramètre et d'y ajouter les 3 caractères suivants : "/X86". La preuve en image :

Il ne reste plus qu'à lancer le package!

• Microsoft Office SharePoint Server 2010
• Windows Office SharePoint Foundation 2010
• Microsoft Office SharePoint Server 2007
• Microsoft Office SharePoint Portal Server 2003
• Windows SharePoint Services version 3.0
• Windows SharePoint Services version 2.0 

Pour la sauvegarde et la restauration de sites Sharpoint, il existe un outil par défaut nommé STSADM.

Cet exe est disponible sous "C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\BIN\stsadm.exe", il vous permet d'effectuer :

• Une sauvegarde : stsadm -o backup -url http://[url-du-site] -filename [fichier.dat]
• Une restauration : stsadm -o restore -url http://[url-du-site] -filename [fichier.dat]

 PS : La commande -overwrite permet d'écraser un site existant lors d'une restauration.

Attention, s'il ne s'agit pas du même domaine, il sera nécessaire de réappliquer le compte administrateur par défaut puis remmettre à jour tous les autorisations.

L'équipe de développeur de Windows Seven a pensé aux PowerUsers et AdminSys en créant une  super panneau de configuration permettant de gérer Windows Seven dans son ensemble.

Pour découvrir ce mode, créez un nouveau dossier que vous nommerez « GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} ».

Cette nouvelle fonctionnalité apparaitra avec l'icône suivante :

Je vous laisse découvrir la bête...