Hi,
When exporting my report to excel, the column widths change resulting in mis
alignment, and certain columns being place on new pages, which is not very
user friendly at all.
Is there anyway that I can prevent this from happening?
ThanksRob, we had this problem too, and it happens in Excel exports too. The
solution for us was to make sure the overall report with was less than 29cm
and that any Graphics were optimised to the size displayed in the report
(rather than the report shrinking the graphics, for some reason, if the
actual size of the graphic meant that the edge would be displayed off the
page, this would trigger a form feed?)
Hope this helps
Mikey :o)
"Rob" <kothesit@.newsgroup.nospam> wrote in message
news:Ou9TA0ayHHA.2224@.TK2MSFTNGP02.phx.gbl...
> Hi,
> When exporting my report to excel, the column widths change resulting in
> mis alignment, and certain columns being place on new pages, which is not
> very user friendly at all.
> Is there anyway that I can prevent this from happening?
> Thanks
>|||Hi Rob ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community 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.
Showing posts with label changing. Show all posts
Showing posts with label changing. Show all posts
Wednesday, March 7, 2012
Column widths are changing when deploying report
I designed a report in VS.Net 2003. It was actually an existing RDL file
that I just modified for my new report, adding some columns and doing various
formatting things.
In VS when I look at the report design, I have the report at 8.5 in high by
11 in wide with .25 in margins all around. I have 2 columns on the right
side of the table that, when deployed and viewed in PDF, are wider than the
width I defined for the column. For all cells in the columns Can Grow is
false. I have tried moving things all over the place but it won't affect
these two columns, they always stay as wide as they are each time.CanGrow only applies to vertical sizes, not horizontal sizes. The only
things that will grow horizontally are matrices and sized images. Do you
have any images?
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"AdamB" <AdamB@.discussions.microsoft.com> wrote in message
news:1E9C6385-B0D0-44DC-95D8-B0317A3F07A5@.microsoft.com...
>I designed a report in VS.Net 2003. It was actually an existing RDL file
> that I just modified for my new report, adding some columns and doing
> various
> formatting things.
> In VS when I look at the report design, I have the report at 8.5 in high
> by
> 11 in wide with .25 in margins all around. I have 2 columns on the right
> side of the table that, when deployed and viewed in PDF, are wider than
> the
> width I defined for the column. For all cells in the columns Can Grow is
> false. I have tried moving things all over the place but it won't affect
> these two columns, they always stay as wide as they are each time.|||No, but I seem to have resolved the problem by deleting then recreating the
columns
"Brian Welcker [MS]" wrote:
> CanGrow only applies to vertical sizes, not horizontal sizes. The only
> things that will grow horizontally are matrices and sized images. Do you
> have any images?
> --
> Brian Welcker
> Group Program Manager
> Microsoft SQL Server
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "AdamB" <AdamB@.discussions.microsoft.com> wrote in message
> news:1E9C6385-B0D0-44DC-95D8-B0317A3F07A5@.microsoft.com...
> >I designed a report in VS.Net 2003. It was actually an existing RDL file
> > that I just modified for my new report, adding some columns and doing
> > various
> > formatting things.
> >
> > In VS when I look at the report design, I have the report at 8.5 in high
> > by
> > 11 in wide with .25 in margins all around. I have 2 columns on the right
> > side of the table that, when deployed and viewed in PDF, are wider than
> > the
> > width I defined for the column. For all cells in the columns Can Grow is
> > false. I have tried moving things all over the place but it won't affect
> > these two columns, they always stay as wide as they are each time.
>
>
that I just modified for my new report, adding some columns and doing various
formatting things.
In VS when I look at the report design, I have the report at 8.5 in high by
11 in wide with .25 in margins all around. I have 2 columns on the right
side of the table that, when deployed and viewed in PDF, are wider than the
width I defined for the column. For all cells in the columns Can Grow is
false. I have tried moving things all over the place but it won't affect
these two columns, they always stay as wide as they are each time.CanGrow only applies to vertical sizes, not horizontal sizes. The only
things that will grow horizontally are matrices and sized images. Do you
have any images?
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"AdamB" <AdamB@.discussions.microsoft.com> wrote in message
news:1E9C6385-B0D0-44DC-95D8-B0317A3F07A5@.microsoft.com...
>I designed a report in VS.Net 2003. It was actually an existing RDL file
> that I just modified for my new report, adding some columns and doing
> various
> formatting things.
> In VS when I look at the report design, I have the report at 8.5 in high
> by
> 11 in wide with .25 in margins all around. I have 2 columns on the right
> side of the table that, when deployed and viewed in PDF, are wider than
> the
> width I defined for the column. For all cells in the columns Can Grow is
> false. I have tried moving things all over the place but it won't affect
> these two columns, they always stay as wide as they are each time.|||No, but I seem to have resolved the problem by deleting then recreating the
columns
"Brian Welcker [MS]" wrote:
> CanGrow only applies to vertical sizes, not horizontal sizes. The only
> things that will grow horizontally are matrices and sized images. Do you
> have any images?
> --
> Brian Welcker
> Group Program Manager
> Microsoft SQL Server
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "AdamB" <AdamB@.discussions.microsoft.com> wrote in message
> news:1E9C6385-B0D0-44DC-95D8-B0317A3F07A5@.microsoft.com...
> >I designed a report in VS.Net 2003. It was actually an existing RDL file
> > that I just modified for my new report, adding some columns and doing
> > various
> > formatting things.
> >
> > In VS when I look at the report design, I have the report at 8.5 in high
> > by
> > 11 in wide with .25 in margins all around. I have 2 columns on the right
> > side of the table that, when deployed and viewed in PDF, are wider than
> > the
> > width I defined for the column. For all cells in the columns Can Grow is
> > false. I have tried moving things all over the place but it won't affect
> > these two columns, they always stay as wide as they are each time.
>
>
Sunday, February 12, 2012
Collations Problem
I have recently migrated a SQL Server 6.5 DB to SQL 2000.
On a particular table i added a new varchar ( [field29] - see below)
now when changing a record in this table, the performance is greatly reduced.
In SQL Enterprise manager, doing a return all rows, and then amending a record here, i get the following message :
"the entire resultset must be returned before this row can be updated. This operation is in progress and may take a long time due to the size of the result set".
The table has 300,000 records. The update takes about 20secs.
After this has completed, the performance is ok, as long as the window remains open. SQL Server memory also grows significantly. It appears that the entire recordset is cached.
Is this related to Collations?
([Field1] is the Primary Key)
any ideas?
CREATE TABLE [dbo].[Tabletest]
(
[field1] [varchar] (9) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL ,
[field2] [smallint] NOT NULL ,
[field3] [datetime] NOT NULL ,
[field4] [datetime] NULL ,
[field5] [datetime] NULL ,
[field6] [datetime] NULL ,
[field7] [varchar] (30) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL ,
[field8] [varchar] (30) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field9] [varchar] (30) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field10] [varchar] (250) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field11] [varchar] (6) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL ,
[field12] [smallint] NOT NULL ,
[field13] [varchar] (6) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field15] [smallint] NULL ,
[field16] [smallint] NULL ,
[field17] [smallint] NULL ,
[field18] [smallint] NULL ,
[field19] [smallint] NULL ,
[field20] [smallint] NULL ,
[field21] [smallint] NULL ,
[field22] [varchar] (60) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field23] [smallint] NOT NULL ,
[field24] [bit] NOT NULL ,
[field25] [datetime] NULL ,
[field26] [varchar] (9) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field27] [int] NOT NULL ,
[field28] [smallint] NULL ,
[field29] [varchar] (50) COLLATE SQL_Latin1_General_CP850_CI_AS NULL
)Use WHERE clause, you do not need to see 300,000 records when you are changing one :)
On a particular table i added a new varchar ( [field29] - see below)
now when changing a record in this table, the performance is greatly reduced.
In SQL Enterprise manager, doing a return all rows, and then amending a record here, i get the following message :
"the entire resultset must be returned before this row can be updated. This operation is in progress and may take a long time due to the size of the result set".
The table has 300,000 records. The update takes about 20secs.
After this has completed, the performance is ok, as long as the window remains open. SQL Server memory also grows significantly. It appears that the entire recordset is cached.
Is this related to Collations?
([Field1] is the Primary Key)
any ideas?
CREATE TABLE [dbo].[Tabletest]
(
[field1] [varchar] (9) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL ,
[field2] [smallint] NOT NULL ,
[field3] [datetime] NOT NULL ,
[field4] [datetime] NULL ,
[field5] [datetime] NULL ,
[field6] [datetime] NULL ,
[field7] [varchar] (30) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL ,
[field8] [varchar] (30) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field9] [varchar] (30) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field10] [varchar] (250) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field11] [varchar] (6) COLLATE SQL_Latin1_General_CP850_CI_AS NOT NULL ,
[field12] [smallint] NOT NULL ,
[field13] [varchar] (6) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field15] [smallint] NULL ,
[field16] [smallint] NULL ,
[field17] [smallint] NULL ,
[field18] [smallint] NULL ,
[field19] [smallint] NULL ,
[field20] [smallint] NULL ,
[field21] [smallint] NULL ,
[field22] [varchar] (60) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field23] [smallint] NOT NULL ,
[field24] [bit] NOT NULL ,
[field25] [datetime] NULL ,
[field26] [varchar] (9) COLLATE SQL_Latin1_General_CP850_CI_AS NULL ,
[field27] [int] NOT NULL ,
[field28] [smallint] NULL ,
[field29] [varchar] (50) COLLATE SQL_Latin1_General_CP850_CI_AS NULL
)Use WHERE clause, you do not need to see 300,000 records when you are changing one :)
Subscribe to:
Posts (Atom)