report to excel - total's shift

  • Thread starter יריב החביב
  • Start date
×

יריב החביב

hello,

i have report with total's under the column's (left and right).

when i print it to excel, the total's shift the position.

the field who sum's the left column go under the record

of the right column and the field who sum's the right column go under the

record's of the left column.

what can i do ?
 
A

Arvin Meyer [MVP]

I believe this is a bug in Excel. There is a MS KB article on it, but I
don't believe that it addresses the full extent of the problem. The best I
can figure is that it is caused by nulls in columns. You cannot easily deal
with it in a formatted report, and Microsoft no longer lets you print a
report to Excel, due to a legal issue. If you export the underlying query,
you can pad out the empty (null) values with a 0, and the Excel spreadsheet
will be correct.

One other possible problem may be the export of text into Excel as a CSV
file. If that is done, and there are commas in a value, Excel interprets
that as a new column. The only fix for that is to remove the commas.
 
A

aaron_kempf

again-- this isn't a bug in Excel-- this is a bug in Access.

Move to Reporting Services if you do _ANYTHING_ involving exporting to
Excel.

-Aaron
 
A

Arvin Meyer [MVP]

So here's the article:

http://support.microsoft.com/kb/823222/en-us

The data is shown correctly in Access, but incorrectly in Excel. The error
also occurs in ADPs, and BTW, similar errors occurred in SQL-Server 2005
when writing to Excel, but were fixed with Service Packs and hotfixes.

I can't agree that rewriting an entire database is a solution to fixing a
small easily fixed bug.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

again-- this isn't a bug in Excel-- this is a bug in Access.

Move to Reporting Services if you do _ANYTHING_ involving exporting to
Excel.

-Aaron
 
A

aaron_kempf

Oh so what you're trying to tell me.. is that the SQL team _FIXED_ a
problem and the Access team _DID_NOT_?

Thanks for bringing this to my attention; it is just another symptom
that SQL Server is where you should put your efforts-- because
Microsoft _CARES_ about SQL Server enough to fix bugs.

PS - is there a way to see version history for these bugs?? I'd be
interested in seeing more background on this.. Don't make me spider in
order to collect all the bugs over time (and keep track of bug version
history myself); thanks ;)

-Aaron
 
A

Arvin Meyer [MVP]

You know that you're hopeless. I'm sorry I wasted any time at all with you.
I make much better use of my time helping real users.

PLONK
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

Oh so what you're trying to tell me.. is that the SQL team _FIXED_ a
problem and the Access team _DID_NOT_?

Thanks for bringing this to my attention; it is just another symptom
that SQL Server is where you should put your efforts-- because
Microsoft _CARES_ about SQL Server enough to fix bugs.

PS - is there a way to see version history for these bugs?? I'd be
interested in seeing more background on this.. Don't make me spider in
order to collect all the bugs over time (and keep track of bug version
history myself); thanks ;)

-Aaron
 
A

aaron_kempf

helping real users?

what are there really hundreds of little midgets out there in the
'real world' that need midget-sized databases?

ROFL

Honestly-- Stick on topic.
Microsoft _FIXED_ the bug in SQL Server-- but not in Access.

What does _THAT_ tell you about Microsofts commitment to Access?
Seriously-?

Don't attack me kid; because you've been outsmarted by an MCITP: DBA.

-Aaron
 
×

יריב החביב

Om namo narayanay,

Thanks you both very much.

I learn a lot from your discussion.


om shanti shanti shanti
 
Top