Lors de l'utilisation de la commande OSQL,
vous avez la possibilité de lancer des fichiers de commandes .sql, très pratique pour mettre en production l'initialisation d'un Datawarehouse.

Ces fichiers de requêtes SQL utilisent la commande INSERT dans des champs de type varchar.
si le fichier contient des "ï,é..." il seront passés en caractères spéciaux du type "U,É...".
Cette erreur vient de l'interprétation du fichier via la commande OSQL.

la solution que j'utilise aujourd'hui, est la convertion du fichier SQL de ANSI en unicode.

Passé ce problème l'utilisation de OSQL reste très simple : depuis command ou dans un .bat la ligne suivante permet le lancement d'un fichier SQL
osql -E -S "votre serveur" -i Script.sql

La problématique est de proposer un portail sur SSRS qui dispose de :

* 2 datasets, un SSAS et un SQL Server
* une page d’accueil classique à base de requête SQL : A
* une navigation dans un cube en format matrice : MM
* une navigation dans un cube en format liste : ML
* une page de détail à base de requête SQL : D

Les navigations RS détaillées dans ce post sont : A > MM > ML > D.

En comprenant les syntaxes utilisées pour ces sauts il est possible de monter un réseau complet depuis n'importe quel type de rapport vers n'importe quel autre.

La principale difficulté dans ce type d’architecture repose sur le passage des paramètres entre les 2 technologies.

Il est à noter que le sujet de la sécurité ne sera pas abordé. En effet selon les best practices il est nécessaire de définir la sécurité des données au niveau des bases (SSAS ou SQL Server) et non au niveau de l’outil de reporting, afin de garantir le même niveau de sécurité selon tous les modes d’accès.

Toutes les syntaxes détaillées ci-dessous sont à définir dans la fenêtre paramètre de l’onglet navigation de la zone devant disposer du lien.

1 - A > MM
Dans ce saut de rapport, une valeur SQL est passée à un rapport branché sur cube. Le paramètre attendu par le cube est une coordonnée de dimension permettant de filtrer les données. Il est donc nécessaire de transformer la valeur pour qu’elle adopte le format attendu :

ParamètreAttendu
="[Dimension].[Hiérarchie].[Niveau].&["+ Fields!ChampSQL.Value +"]"

2 - MM > ML
Dans notre exemple 2 valeurs sont transmises à ML :

La première provient du dataset de MM. Attention au fait que ce n’est pas la valeur du champ qu’il faut transmettre mais bien sa coordonnée dans le cube. On ne transmet donc pas à ML une Value mais un UniqueName qui correspond à cette coordonnée:
ParamètreAttendu

=Fields!ChampDeLaDimensionAttendue("UniqueName")

Pour la seconde valeur, qui est fournie par le paramètre de DimTemps de MM, la syntaxe est la Value, car dans cette value est stockée une coordonnée MDX qui dans notre cas provient du point 1 :
ParamètreAttendu
=Parameters!NomDuParametre.Value


3 - ML > D
Enfin, pour passer de ML à D, il suffit simplement de transmettre la valeur du champ attendu et non ses coordonnées comme précédemment. La propriété Value suffit donc :
ParamètreAttendu
=Fields!ChampDeLaDimensionAttendue.Value


Et voilà !
Facile en fin de compte ;)

Suite à une demande, l'objectif de ce post est de décrire la méthode d'alimentation des Tables AuditPkgExecution,AuditTableProcessing et AuditDimension que J'utilise dans mes projets avec SSIS:

• Description des tables

AuditPkgExecution est utiliser pour le controle des Packages donc lors de l'exection de mon Etl il y aura autant d'insertion de lignes que de packages.
AuditTableProcessing represente Les flux de données (DataFlow), dans certains cas j'ai réalisé plusieurs insertions dans cette table pour un DataFlowAuditDimension est utiliser dans le cadre ou la table Alimenté est une dimension d'un Datawarehouse

• Alimentation des Tables

Dans chaque Package je crée des conteneur de sequence Pré-Execute et Post-Execute, il est aussi important dasn les DataFlow d'utiliser le composant "Nombre de lignes" pour réaliser des comptages aux endroit stategiques :
- ExtractRowCnt (Nombre de ligne extraite de la source)
- ExtractCheckValueXxxxx (Nombre de ligne après un traitement specifique)
- InsertRowCnt (Nombres de lignes Insérés)
- UpdateRowCnt (Nombres de lignes Updatés)
- ErrorRowCnt(Nombre de lignes en Erreur)
Les variables TableInitialRowCnt et TableFinalRowCnt seront alimentés avec des requettes

AuditPkgExecution : Principalement alimentée avec des variables systemes, à noté que le Master n'a pas de ParentPkgExeckey, les autres packages prendront comme valeur de ParentPkgExeckey le PkgExecKey du master. ce point sera traité avec l'utilisation des configurations dans SSIS et les variables parent.
AuditTableProcessing : pour chaque ETL cette table sera diferente mais on y retrouvera souvant les standart: Nom de la table, Nombre de lignes inserrées,Mises à jour, Suprimmées, en Erreur... pour chaque cas metier traité ou pour la gestion de rejets.
AuditDimension : personnelement je ne l'utilise que dans le cadre ou mes dimensions sont alimentés en plusieurs phases ou sur des Flocons.

Vous le savez sans doute deja, mais chaque outil de SQL Serveur 2005 à son propre mode de deployement, je me suis donc attaché à trouver un mode pour chacun. Dans le cadre ou je souhaite laisser un livrable pret à installer par mon client ou mon service d'exploitation.
Très vite on trouvera le generateur de "deployement manifest" de SSIS ainsi que les fichier de publication de SSAS à utiliser avec l'assitant de deployement.
Pour SSRS ce point est bien plus complexe.
Les choix qui s'offre à nous :
- Deploiement via Visual Studio
- Deplacement des fichiers RDL
...
Après quelques recherche je suis tomber sur le pilotage de l'application RS.exe via un fichier RSS.
il nous faut donc plusieurs elements pour effectuer un livraison avec ce mode
1 Fichier .RSS
1 Fichier .Bat (pour lancer le tout)
x fichiers .Rdl