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

Afin de disposer des propriétés ParentUniqueName ou Level dans les rapports de SSRS, il peut être utile de formuler sa requête MDX comme suit.

En effet dans le cas de dimensions parent-enfant SSRS arrive à communiquer avec SSAS pour obtenir ces infos. Pour toutes les autres dimensions cela ne fonctionne pas, et l'utilisation de cette syntaxe permet de contourner ce manque et de disposer des propriétés attendues. Pour certains rapports tordus cela peut être bien utile!


WITH

MEMBER [Measures].[UniqueName] as axis(1).item(0).item(0).hierarchy.currentmember.uniquename
MEMBER [Measures].[ParentUniqueName] as axis(1).item(0).item(0).hierarchy.currentmember.parent.uniquename
MEMBER [Measures].[P2UniqueName] as axis(1).item(0).item(0).hierarchy.currentmember.parent.parent.uniquename
MEMBER [Measures].[ParentName] as axis(1).item(0).item(0).hierarchy.currentmember.parent.name
MEMBER [Measures].[Name] as axis(1).item(0).item(0).hierarchy.currentmember.name
MEMBER [Measures].[Level] as axis(1).item(0).item(0).hierarchy.currentmember.level.ordinal

SELECT

{[Measures].[UniqueName],[Measures].[ParentUniqueName], [Measures].[Name], [Measures].[ParentName], [Measures].[P2UniqueName] , [Measures].[Level], [Measures].[Nb Employés] } ON COLUMNS,

NonEmpty(
{ STRTOMEMBER(@DimOrganisationOrganisation, CONSTRAINED).CHILDREN
}) ON ROWS

FROM [CubeDWH]
WHERE (STRTOSET(@DimTempsTemps, CONSTRAINED))

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 ;)

Voici une bonne solution pour traiter des fichiers dont le nombre de colonnes est variable.
Ce type de fichier est classique quand Excel est utilisé pour générer des CSV à traiter dans SSIS.

Solution sans script:
http://agilebi.com/cs/blogs/jwelch/archive/2007/05/16/handling-varying-columns-part-2.aspx


Solution avec script:
http://agilebi.com/cs/blogs/jwelch/archive/2007/05/08/handling-flat-files-with-varying-numbers-of-columns.aspx

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.