I am getting a "Damage to the file was so extensive that repairs were not
possible. Excel attemted to recover your formulas and values, but some data
may have been lost or corrupted." in some instances when exporting to excel.
I have noticed that a couple other list members have also reported this
issue, but have been unable to narrow down the exact cause of the problem
(see post by DJJIII on 7/13/2005 subject: excel export /collapsed fails to
render excel file)
The interesting thing in my case is that I have a fairly complex report with
many charts and tables. My "top level" report throws this excel error.
However, if I add parameters ("drill down report") the structure of the
report is exactly the same with charts and tables, just less (or different)
data and then it renders fine. Incidentally the top-leve report has params
too, so having parameters itself is not the issue. I am not using groups at
all, so I don't think the issue is directly related to the use of groups as
was suspected in the post by DJJIII.
My guess is there is some data-related issue as our same report (both
top-level and drilldown) with different data works fine.
Our report actually is a collection of 10 or so subreports, so I will be
doing a little debugging by removing subreports to see if I can identify the
subreport or data that is causing the issue.
Microsoft, please let us know if there has been a confirmed issue related to
this and what causes the problem. I would be happy to provide an RDL, excel
file, etc. to help you resolve the issue.
Thanks, DavidI have run into the exact same issue except - my report is essentially a flat
file export. I do not have multiple leves, diagrams or charts.
The only difference I can isolate is a "comments" field that is provided to
users. They record pages and pages of text in this field. If I remove the
field it renders just fine. If I include it then error. So, either the field
length limit in excel? or a special character the users are including that
excel cannot handle? Just guesses.
Any help or fixes would be appreciated. Without this information & the
ability to export to excel the report is considered useless by the users.
Thank you.
--Cory
"David Swanson" wrote:
> I am getting a "Damage to the file was so extensive that repairs were not
> possible. Excel attemted to recover your formulas and values, but some data
> may have been lost or corrupted." in some instances when exporting to excel.
> I have noticed that a couple other list members have also reported this
> issue, but have been unable to narrow down the exact cause of the problem
> (see post by DJJIII on 7/13/2005 subject: excel export /collapsed fails to
> render excel file)
> The interesting thing in my case is that I have a fairly complex report with
> many charts and tables. My "top level" report throws this excel error.
> However, if I add parameters ("drill down report") the structure of the
> report is exactly the same with charts and tables, just less (or different)
> data and then it renders fine. Incidentally the top-leve report has params
> too, so having parameters itself is not the issue. I am not using groups at
> all, so I don't think the issue is directly related to the use of groups as
> was suspected in the post by DJJIII.
> My guess is there is some data-related issue as our same report (both
> top-level and drilldown) with different data works fine.
> Our report actually is a collection of 10 or so subreports, so I will be
> doing a little debugging by removing subreports to see if I can identify the
> subreport or data that is causing the issue.
> Microsoft, please let us know if there has been a confirmed issue related to
> this and what causes the problem. I would be happy to provide an RDL, excel
> file, etc. to help you resolve the issue.
> Thanks, David|||Hello David & Edgar,
There is a known issue that when exporting a report from Reporting Services
SP2 to Excel format results in the following error when trying to open the
Excel workbook:
Microsoft Office Excel File Repair Log
Errors were detected in file 'C:\Documents and Settings\<username>\Local
Settings\Temporary Internet Files\Content.IE5\4H4BKNSF\Report2[1].xls'
The following is a list of repairs:
Damage to the file was so extensive that repairs were not possible. Excel
attempted to recover your formulas and values, but some data may have been
lost or corrupted.
Further investigation indicates that this problem can occur if a field of
data type NTEXT contains more than 4110 characters.
This issue is supposed to be fixed in next edition of SQL reporting service
(sql 2005). If you believe this has big business impact, please contact CSS
open a Support incident with Microsoft Product Support Services so that a
dedicated Support Professional can work with you to evaluate this:
For a complete list of Microsoft Product Support Services phone numbers,
please go to the following address on the World Wide Web:
http://support.microsoft.com/directory/overview.asp
Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--
| Thread-Topic: Damage to file message when exporting to excel
| thread-index: AcWhwO0iSuq0BbqxT5u6w58E6hDj9Q==| X-WBNR-Posting-Host: 134.131.125.49
| From: "=?Utf-8?B?Q29yeQ==?=" <Cory@.discussions.microsoft.com>
| References: <48600043-4159-4924-9CD6-3AAE2565F6D7@.microsoft.com>
| Subject: RE: Damage to file message when exporting to excel
| Date: Mon, 15 Aug 2005 10:44:03 -0700
| Lines: 48
| Message-ID: <EA86AEA5-D0AE-47E8-90BB-AAAA28FCF022@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.sqlserver.reportingsvcs
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.reportingsvcs:50386
| X-Tomcat-NG: microsoft.public.sqlserver.reportingsvcs
|
| I have run into the exact same issue except - my report is essentially a
flat
| file export. I do not have multiple leves, diagrams or charts.
|
| The only difference I can isolate is a "comments" field that is provided
to
| users. They record pages and pages of text in this field. If I remove
the
| field it renders just fine. If I include it then error. So, either the
field
| length limit in excel? or a special character the users are including
that
| excel cannot handle? Just guesses.
|
| Any help or fixes would be appreciated. Without this information & the
| ability to export to excel the report is considered useless by the users.
|
| Thank you.
|
| --Cory
|
| "David Swanson" wrote:
|
| > I am getting a "Damage to the file was so extensive that repairs were
not
| > possible. Excel attemted to recover your formulas and values, but some
data
| > may have been lost or corrupted." in some instances when exporting to
excel.
| >
| > I have noticed that a couple other list members have also reported this
| > issue, but have been unable to narrow down the exact cause of the
problem
| > (see post by DJJIII on 7/13/2005 subject: excel export /collapsed
fails to
| > render excel file)
| >
| > The interesting thing in my case is that I have a fairly complex report
with
| > many charts and tables. My "top level" report throws this excel error.
| > However, if I add parameters ("drill down report") the structure of the
| > report is exactly the same with charts and tables, just less (or
different)
| > data and then it renders fine. Incidentally the top-leve report has
params
| > too, so having parameters itself is not the issue. I am not using
groups at
| > all, so I don't think the issue is directly related to the use of
groups as
| > was suspected in the post by DJJIII.
| >
| > My guess is there is some data-related issue as our same report (both
| > top-level and drilldown) with different data works fine.
| >
| > Our report actually is a collection of 10 or so subreports, so I will
be
| > doing a little debugging by removing subreports to see if I can
identify the
| > subreport or data that is causing the issue.
| >
| > Microsoft, please let us know if there has been a confirmed issue
related to
| > this and what causes the problem. I would be happy to provide an RDL,
excel
| > file, etc. to help you resolve the issue.
| >
| > Thanks, David
||||I'm experimenting the same thing on one of my reports. I've occurs only when
I'm displaying point labels on which I apply this function :
=ROUND((Fields!CHANGE.Value)*100).TOSTRING & " %"
so there are no ntext field involved here. (I have a work around for my
problem but it requires quit a bit of code change database side)
I'm on RS 2000 sp1 (we haven't applied sp 2 yet because of custom code that
crashes under sp 2. We will be migrating to SQL 2005 in 2 to 3 months.)
thx
Fred
"Peter Yang [MSFT]" wrote:
> Hello David & Edgar,
> There is a known issue that when exporting a report from Reporting Services
> SP2 to Excel format results in the following error when trying to open the
> Excel workbook:
> Microsoft Office Excel File Repair Log
> Errors were detected in file 'C:\Documents and Settings\<username>\Local
> Settings\Temporary Internet Files\Content.IE5\4H4BKNSF\Report2[1].xls'
> The following is a list of repairs:
> Damage to the file was so extensive that repairs were not possible. Excel
> attempted to recover your formulas and values, but some data may have been
> lost or corrupted.
> Further investigation indicates that this problem can occur if a field of
> data type NTEXT contains more than 4110 characters.
> This issue is supposed to be fixed in next edition of SQL reporting service
> (sql 2005). If you believe this has big business impact, please contact CSS
> open a Support incident with Microsoft Product Support Services so that a
> dedicated Support Professional can work with you to evaluate this:
> For a complete list of Microsoft Product Support Services phone numbers,
> please go to the following address on the World Wide Web:
> http://support.microsoft.com/directory/overview.asp
> Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> =====================================================>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> --
> | Thread-Topic: Damage to file message when exporting to excel
> | thread-index: AcWhwO0iSuq0BbqxT5u6w58E6hDj9Q==> | X-WBNR-Posting-Host: 134.131.125.49
> | From: "=?Utf-8?B?Q29yeQ==?=" <Cory@.discussions.microsoft.com>
> | References: <48600043-4159-4924-9CD6-3AAE2565F6D7@.microsoft.com>
> | Subject: RE: Damage to file message when exporting to excel
> | Date: Mon, 15 Aug 2005 10:44:03 -0700
> | Lines: 48
> | Message-ID: <EA86AEA5-D0AE-47E8-90BB-AAAA28FCF022@.microsoft.com>
> | MIME-Version: 1.0
> | Content-Type: text/plain;
> | charset="Utf-8"
> | Content-Transfer-Encoding: 7bit
> | X-Newsreader: Microsoft CDO for Windows 2000
> | Content-Class: urn:content-classes:message
> | Importance: normal
> | Priority: normal
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> | Newsgroups: microsoft.public.sqlserver.reportingsvcs
> | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
> | Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA03.phx.gbl
> | Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.reportingsvcs:50386
> | X-Tomcat-NG: microsoft.public.sqlserver.reportingsvcs
> |
> | I have run into the exact same issue except - my report is essentially a
> flat
> | file export. I do not have multiple leves, diagrams or charts.
> |
> | The only difference I can isolate is a "comments" field that is provided
> to
> | users. They record pages and pages of text in this field. If I remove
> the
> | field it renders just fine. If I include it then error. So, either the
> field
> | length limit in excel? or a special character the users are including
> that
> | excel cannot handle? Just guesses.
> |
> | Any help or fixes would be appreciated. Without this information & the
> | ability to export to excel the report is considered useless by the users.
> |
> | Thank you.
> |
> | --Cory
> |
> | "David Swanson" wrote:
> |
> | > I am getting a "Damage to the file was so extensive that repairs were
> not
> | > possible. Excel attemted to recover your formulas and values, but some
> data
> | > may have been lost or corrupted." in some instances when exporting to
> excel.
> | >
> | > I have noticed that a couple other list members have also reported this
> | > issue, but have been unable to narrow down the exact cause of the
> problem
> | > (see post by DJJIII on 7/13/2005 subject: excel export /collapsed
> fails to
> | > render excel file)
> | >
> | > The interesting thing in my case is that I have a fairly complex report
> with
> | > many charts and tables. My "top level" report throws this excel error.
> | > However, if I add parameters ("drill down report") the structure of the
> | > report is exactly the same with charts and tables, just less (or
> different)
> | > data and then it renders fine. Incidentally the top-leve report has
> params
> | > too, so having parameters itself is not the issue. I am not using
> groups at
> | > all, so I don't think the issue is directly related to the use of
> groups as
> | > was suspected in the post by DJJIII.
> | >
> | > My guess is there is some data-related issue as our same report (both
> | > top-level and drilldown) with different data works fine.
> | >
> | > Our report actually is a collection of 10 or so subreports, so I will
> be
> | > doing a little debugging by removing subreports to see if I can
> identify the
> | > subreport or data that is causing the issue.
> | >
> | > Microsoft, please let us know if there has been a confirmed issue
> related to
> | > this and what causes the problem. I would be happy to provide an RDL,
> excel
> | > file, etc. to help you resolve the issue.
> | >
> | > Thanks, David
> |
>
Sunday, February 19, 2012
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment