Pourquoi SSRS exporte-t-il un file XLS corrompu?

J'ai un rapport SSRS dans SQL Server 2012 qui exporte vers Word et PDF qui s'ouvrent dans les lecteurs respectifs. Cependant quand j'ouvre le dossier de XLS dans MS-Excel j'obtiens le message demandant s'il devrait réparer le dossier corrompu. Si je clique sur oui, il affiche un file vide avec le message ci-dessous. J'utilise SQL Server 2012. Cela se produit uniquement pour datatables d'un jour particulier.

Replaced Part: /xl/worksheets/sheet1.xml part with XML error. Illegal xml character. Line 14, column 6935. 

Je suppose que je dois étudier ce post http://christianspecht.de/2014/01/14/excel-found-unreadable-content-when-exporting-a-reporting-services-report/

J'ai eu le même problème et dans mon cas c'était un problème de précision des données. Apparemment, SSRS n'est pas capable de traiter 18 décimales et ma procédure a renvoyé ces données pour certains des champs. C'est ce qui se passe probablement dans votre cas. Les données pour un jour spécifique se terminent juste avec une valeur qui a trop de décimales à traiter par le SSRS.

Une option consiste à modifier le type de données dans la table pour prendre en charge une précision plus faible. Une autre solution consiste à convertir les nombres dans la procédure stockée qui remplit le rapport.

 SELECT CONVERT(NUMERIC(38,8),MyNumber) AS MyNumber_v2 

Vous pouvez en lire plus sur ce bug ici .

J'ai eu le même problème avec le champ de type de pourcentage. Lorsque la valeur 0% apparaît dans la sortie de données, l'export du rapport vers Excel génère un file rompu. Le file Excel auto-réparé contenait 0,00000000000 valeurs au lieu de 0,00% comme prévu. Le type de données de champ initial dans DB était DECIMAL (24,14). J'ai ajouté la clause CONVERT to DECIMAL (10,7) dans la requête et le problème a été résolu.

J'ai eu un problème similaire lors de l'export vers Excel (format xlsx) de SSRS 2012 avec la database Oracle. Mais le message d'erreur était "Nous avons trouvé un problème avec du contenu dans XYZ.xlsx, Voulez-vous que nous essayions de récupérer autant que nous le pouvons? Si vous faites confiance à la source de ce classur, click Oui". Le problème était dû au caractère non imprimable dans l'un des champs. Le problème a été résolu en changeant la requête SQL pour utiliser l'expression régulière comme "select column1, REGEXP_REPLACE (column2, '[^ [: print:]]', '') en tant que colonne2 de la table". Fondamentalement, l'expression régulière supprime tous les caractères non imprimables de column2.

J'ai été confronté à la même situation lors de l'export au format Excel. Dans mon cas, en regardant attentivement la sortie du rapport, j'ai trouvé qu'il y avait un caractère non-ASCII dans la sortie. J'ai enlevé le caractère non-ASCII et après que l'export d'Excel fonctionnait bien. J'ai supprimé le caractère non-ASCII de la colonne contenant en utilisant la fonction suivante.

 CREATE FUNCTION fnc_RemoveNonASCII ( @nssortingng nvarchar(255) ) RETURNS varchar(255) AS BEGIN DECLARE @Result varchar(255) SET @Result = '' DECLARE @nchar nvarchar(1) DECLARE @position int SET @position = 1 WHILE @position <= LEN(@nssortingng) BEGIN SET @nchar = SUBSTRING(@nssortingng, @position, 1) --Unicode & ASCII are the same from 1 to 255. --Only Unicode goes beyond 255 --0 to 31 are non-printable characters IF UNICODE(@nchar) between 32 and 255 SET @Result = @Result + @nchar SET @position = @position + 1 END RETURN @Result END GO 

Extrayez les fonts de cellules (ou d'en-tête de colonne) de votre design de rapport (dans le Générateur de rapports). Peut-être que l'un d'entre eux n'existe pas sur votre machine!