Récemment, il m’a été demandé de trouver pourquoi lors d’un export CSV depuis un rapport SSRS, le fichier était mal formé et les lignes coupées.

Après quelques recherches, il s’est avéré que certains champs contenaient un CHAR(13) c’est-à-dire des Cariage Return (retours à la ligne).

1-Comment le détecter 

Une requête du type :

SELECT REPLACE(monChamp,CHAR(13),’___’) FROM dbo.MaTable

Permet de remplacer le retour à la ligne (invisible depuis SSMS) par un ___ visible.

2-Une cause possible du problème :

D’où viennent ces retours à la ligne ? Rarement du système source, mais c’est bien sûr la première chose à vérifier, je pense que la majorité du temps cela vient d’une mauvaise configuration de l’import de fichier plat.

Prenons l’exemple d’un fichier CSV :

Vous constatez que le retour à la ligne est de type : CR LF

Dans notre collecte nous aurons donc :

Par contre si par erreur nous mettions {LF} à la place de {CR}{LF}, toutes les dernières colonnes de chaque ligne contiendraient un CR résiduel… et cela peut passer inaperçu pendant LONGTEMPS (2 ans dans mon cas )

Le cas du char(1)  start of heading (of the dead) rapporté par Florian Eiden

Encore pire que le CHAR(13), le CHAR(1) ou start of heading (SOH), celui-ci a plusieurs conséquences :

1. Stopper le chargement du flux de données dans SSIS mais sans laisser d’erreurs, la tâche finit avec succès.
2. Rendre impossible la lecture d’un cube (sous certaines conditions).

Pourquoi ?

Le SOH (start of heading) semble interpréter par le XML des packages SSIS et par le XMLA des cubes ce qui brise la cohérence de ces deux types de fichiers et provoque des erreurs curieuses.

Exemple dans SSIS :

Créons une colonne dérivée avec ce fameux caractère :

Maintenant lançons notre package :

Celui-ci finit en success alors que le dataFlow n’est même pas exécuté !!!!

Exemple dans SSAS :

Dans ma dim Customer je glisse un char(1)  sur un nom :

UPDATE[AdventureWorksDW].[dbo].[DimCustomer] SET LastName = CHAR(1)+LastName WHERE LastName='dulac'

Nous constatons bien la présence d’un petit carré dans le champs sous SSMS.

Procéssons ensuite le cube.

Le process est OK.

Naviguons dans les données :

Ça commence mal ! 🙂

Et sous Excel ?

A première vue, excel s’en sort mieux !

Par contre impossible de filtrer sur Dulac

Accompagné d’une jolie erreur dans le profiler :

Échec de l’analyse XML ligne 1, colonne 601: Illegal xml character.
Pour ce qui est de SSMS voici le résultat de la requête suivante:

SELECT [Customer].[Last Name].ALLMEMBERS ON 0
FROM [Adventure Works]Executing the query …

The server sent an unrecognizable response.
 '', hexadecimal value 0x01, is an invalid character. Line 1, position 108495.

Execution complete

En conclusion, Attention aux carractères spéciaux !!!