PowerPivot gère les types suivants :

• Texte
• Entier
• Décimal
• Monétaire
• Date
• Booléen

A la première importation, PowerPivot déduit le type de la colonne en se basant sur le n-premières lignes. (n étant compris entre 1 et 1050 d’après mes tests, je n’ai pas creusé plus).

Cette gestion implicite des types est transparente pour l’utilisateur mais contient quelques subtilités.

La documentation officielle sur Technet

Problème de culture

Le problème que je vais exposer concerne des données financières françaises avec le caractère espace comme séparateur de milliers de type espace :

•   1 456,00
• 99 568,00

Prenons un fichier texte qui contient une colonne de nombre et peu de lignes et/ou que les lignes avec des séparateurs sont en minorité. PowerPivot va bien trouver le type décimal mais ne détecte pas l’espace comme séparateur de milliers. Il supprime donc les lignes avec le séparateur.

Si le fichier contient beaucoup de valeurs avec ce séparateur, PowerPivot déduit que c’est du texte et conserve bien le contenu.

Et pourtant, j’ai bien précisé la culture française.

Dans PowerPivot, le premier réflexe est donc de changer le type de la colonne ; jusqu’ici tout va bien et la colonne est bien convertie, le séparateur de milieu est bien interprété.

Sauf que si vous faites un refresh de la source de données, la donnée est mal convertie pour certaines lignes (celles qui ont 3 digits dans la partie entière et une virgule ; la virgule devient le séparateur de milliers)

951,12 –> 95 112

Comme quoi ce n’est pas le même algo derrière le bouton « Type de données » et celui de la récupération des données.

Sur quelle version de PowerPivot ?

J’ai vu le même problème sur toutes les versions de PowerPivot, que ce soit la v1 (SQL Server 2008 R2), la v2 (SQL Server 2012) ou la v3 actuellement en beta dans Office 15.

J’ai ouvert un item sur Connect pour remonter le problème. Marco Russo avait également remonté un problème similaire avec une source de données SSAS.

Un contournement ?

La solution que j’ai mise en œuvre est de garder le type Texte lié à la source et d’ajouter une colonne avec la formule DAX suivante :  =[col_originale] *1.0.

Ainsi, l’actualisation des données conserve bien l’intégralité de la colonne puisque c’est du texte. Et ensuite, c’est le 2^ème algo qui est utilisé pour la conversion.

Une conclusion ?

Mine de rien, ne pas être vigilant sur ses données peut être catastrophique. En effet, des lignes mal converties ou supprimées peuvent passées totalement inaperçues au rafraichissement mais impliquer des agrégats erronés.

Retenez cette petite check-list :

• Vérifier toujours vos données après l’importation !
• Vérifier toujours vos données après un changement de type (et après un refersh de la Data Source) !
• S’il y a un problème, utilisez un type texte et faites de champs calculés pour maitriser le format
• Des TESTS, Des TESTS, Des TESTS !!
• Proposez une vraie démarche BI avec un DWH et de l’EIM