Web Service RS : modifier des propriétés de rapports

A toujours faire des billets qui expliquent comment faire en sorte que les choses fonctionnent, j’ai envie d'en faire un pour expliquer comment elles ne fonctionnent pas : ça changera. Récemment, chez mon client préféré du moment, nous nous sommes aperçus que le format appliqué aux données dans nos rapports RS n'était pas le bon (date et chiffre au format anglais entre autre). Du coup, je décide de modifier les paramètres de région du serveur (mode bourrin) : surprise, ça ne fonctionne pas. J'ai tout essayé (enfin je crois) et je ne comprends pas pourquoi ça ne passe pas. Je ferai un autre billet sur ce point plus tard.

NT AUTHORITY\SYSTEM n'est plus sysadmin sur 2012

Dans nos tests de compatibilité sur 2012 (typiquement des migrations d'applications) nous nous sommes rendus compte que le login NT AUTHORITY\SYSTEM au niveau de l'instance n'est plus sysadmin sur SQL Server 2012 (c'était encore le cas en 2008 R2). Ce qui pose des problèmes quand, par exemple, vous avec un service Windows tournant avec le compte système local qui tente de piloter des bases de données pour votre application. On passe donc quelques temps à chercher pourquoi nous n'avons pas les droits sur Master afin de pouvoir créer une base par exemple.
La préconisation : ne pas faire tourner ces applications avec le compte système local et utiliser des comptes de domaine si possible. Dans tous les cas, on évite de mettre ce compte système local sysadmin des bases de l'instance SQL.

PowerShell, c'est la vie!

Commes mes fans se sont plaints  hier il y a peu du manque d'activité sur ce blog, voici un petit post pour les réconforter (si je n'ai rien publié depuis, c'est parce que je suis sur l'écriture d'un livre sur SSIS et que je n'ai pas grand chose de nouveau à dire : on se cherche des excuses comme on peut).

J'ai dû mettre en place aujourd'hui il y a peu la création automatique de partition sur SSAS. Ce n'est pas la première fois que je fais ça mais ici, la manière est bien différente car le contexte le requérait. D'habitude, la création de ces partitions s'inscrit dans un process global de mise à jour d'une partie du SID (ETL, DWH, etc...) : le tout est géré par un service Windows custom. Dans ce cas précis, l'AMO est idéal.

Bug de traduction dans AS lors de la modification des types des attributs

Nous venons juste de découvrir un bug marrant dans les traductions de SSAS. Enfin, marrant parce que de prime abord on ne voit pas d’où ça vient, mais qui fait tout de même perdre quelques heures de recherche.

Nous ne comprenions pas pourquoi, lors du procesing de notre dimension temps nous avions ce message d'erreur :

Errors in the back-end database access module. The size specified for a binding was too small, resulting in one or more column values being truncated. Errors in the OLAP storage engine: An error occurred while the 'Fiscal Quarter' attribute of the 'Time' dimension from the MyCube' database.

Généralement, ce message survient lorsque le dimensionnement des types de nos attributs ne correspond pas à celui des colonnes de la base de données source. Après avoir vérifié plusieurs fois et sur tous les attributs de notre dimension, il en résulte que tout est bien fait. Donc après avoir injustement accusé un de mes collègues, l'attribut en question est supprimé, puis recrée. Oh miracle, le problème de processing disparaît. Bref, impossible de savoir d'où cela vient.

A mes yeux, il n'y a plus qu'une solution pour trouver la source du problème : faire un différentiel du XML entre les deux versions des dimensions. En faisant cela, on se rend compte que la traduction associé à l'attribut Fiscal Quarter possède le bon DataType, mais pas le bon DataSize.

Conclusion : cela vient du fait que le type de l'attribut a été modifié après la mise en place de la traduction. Ce procédé n'entraîne donc pas une mise à jour automatique des objets associés (tels que ceux de la traduction). La seule possibilité pour contourner le problème est de supprimer puis recréer la traduction pour l'attribut. Pas cool, sauf si vous connaissez une solution plus simple.

Comportement du Many to Many avec plusieurs dimensions de jointure

Chez nos clients préférés, nous tombons bien souvent sur une modélisation un peu bizarre d'un cube AS. Bien sûre, il y a toujours une justification à cela car cette modélisation a été mise en place pour répondre à un besoin bien précis.
Voici ladite modélisation (ça sera notre cas n°1) :

Un nouveau must read sur AS

Je n'ai pas pour habitude de le faire, mais j'annonce la publication d'un nouveau livre blanc : AS Operations Guide
J'étais justement en train d'écrire un article assez détaillé qui résume la configuration à apporter à AS dans un environnement gros serveurs et multi-users, ce que je fais depuis un an chez mon client. C'est plus la peine maintenant, les informations se trouvent dans ce document.
C'est un peu aussi pour me justifier du laps de temps entre maintenant et mon dernier post, je l'admets. Mais des documents de cette qualité vous enlève toute volonté d'en écrire pour le moment (je l'avoue, c'était un objectif :) )., surtout quand on voit la liste des auteurs.
Bravo à eux.

Attach/Detach manuel sur SSAS 2005

Le procédé de mise en ligne/mise hors ligne ou Attach/Detach d'une base (bien pratique quelque fois) est une feature apparue à partir de 2008.
Forcément en 2005, gros soucis pour réaliser cette opération, d'où mon problème du jour : la réinstallation d'une instance AS 2005 dont seuls les disques de données de l'ancienne instance ont été conservés (avec les répertoire ".db", c'est déjà ça) : bien entendu, on veut récupérer ces bases dont on ne dispose pas de backups (seulement les répertoires contenant les data file).

Si vous gérez vos instances 2005 avec SSMS 2008, effectivement, dans le menu contextuel il y a bien possibilité de faire un Detach de votre base : autant vous dire tout de suite que ça ne fonctionne pas.

Donc deux solutions :

• Soit vous modifiez dans le fichier de configuration de votre instance AS la propriété Datadir en renseignant le chemin du répertoire qui contient vos anciennes données, puis redémarrage de l'instance pour prendre en compte cette modification, puis backup des bases, puis re-changement du Datadir avec le chemin du répertoire de données initial, puis re-redémarrage de l'instance et enfin un Restore des backups nouvellement créés. Méthode la plus propre, mais lourde, surtout si vous avez 20 bases à sauvegarder puis à remonter.
• Ou L'AUTRE méthode, un peu plus brutale mais qui permet de gagner du temps : un copier-coller des anciens répertoires ".db", des fichiers XML ".db.xml", du master.vmp et du CryptKey.bin dans votre répertoire de données actuel, un redémarrage de l'instance et le tour est joué. Bien entendu, ceci fonctionne avec une instance "à vide", sans base de données présente au préalable. Sinon, elle seront supprimées au redémarrage de l'instance car non référencées dans le nouveau (ancien) fichier master.vmp.