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.