layout problem

Hi,
I have 4 subreports in a report and adjust thier position well on layout
tag.
Preview on the report designer everything is fine.
But deploy to report server and browse on IE the subreports all on the wrong
position!
How can I resolve this problem?
Thanks for help!
AngiI had the same problem with some of my reports I found out the only way
ot get the layout right is to enter the location for each item on the
report in the location property and " measure/space" so nothing is over
laping. One can begin where one ends but if they overlap the location
it will be moved to onther page. It still looks a little funny on the
browser but it prints perfectly.sql

Layout Issue

I have a dataset that goes like this

1

2

3

4

5

6

Using a table control, report preview appears as above.

I want the report to look like

1 2 3

4 5 6

How can I generate a report like this ?

Thanks

Is there any other control I can use to get the desired output.

Thanks !!

Large fields freeze the report generation

Hi Group,
I have this subreport that displays information from 2 fields of type
nvarchar(4000).
If I try to preview the subreport from the designer, everything works fine -
there are about 2 pages of information displayed. Export to pdf works
normally.
After deploying it on the server, if I use the
http://server_name/Reports/... again everything works fine. Exporting to pdf
produces a 2-3 pages file in about 10 seconds.
The report that contains this subreport works fine - export to pdf goes
through with no problems.
But if I try to use our application that generates / displays the reports,
it just hangs there, after calling the Render method.
The aspnet_wp process on the server stays at about 93% until the Render
method times out (approx. 10 minutes).
I tried removing the two large nvarchar fields from the subreport - the
report starts working fine like any other report.
The information that should be displayed in the report is not even so much -
as I said before, it should generate about 2-3 pages in pdf.
We have more than 200 reports working fine, none of them complained about
large nvarchar fields.
Did anybody have this type of problem ?
Please help !
Thank you,
Andrei.Correction :
After more tests, this is what I have:
Generating the main report with the Report Manager on the server
(http://server/Reports/...) produces an output in 10 seconds.
But trying to export as PDF will lock the process until timeout.
If I remove the fields of type nvarchar(4000) from the SUBreport, then the
report export to PDF works fine.
Generating the SUBreport with the Report Manager on the server
(http://server/Reports/...) produces an output in less than 10 seconds
The export to PDF works fine.
Thank you,
Andrei.
"Andrei" <andrei.toma@.era-environmental.com> wrote in message
news:esEORK8EHHA.2464@.TK2MSFTNGP06.phx.gbl...
> Hi Group,
> I have this subreport that displays information from 2 fields of type
> nvarchar(4000).
> If I try to preview the subreport from the designer, everything works
> fine - there are about 2 pages of information displayed. Export to pdf
> works normally.
> After deploying it on the server, if I use the
> http://server_name/Reports/... again everything works fine. Exporting to
> pdf produces a 2-3 pages file in about 10 seconds.
> The report that contains this subreport works fine - export to pdf goes
> through with no problems.
> But if I try to use our application that generates / displays the reports,
> it just hangs there, after calling the Render method.
> The aspnet_wp process on the server stays at about 93% until the Render
> method times out (approx. 10 minutes).
> I tried removing the two large nvarchar fields from the subreport - the
> report starts working fine like any other report.
> The information that should be displayed in the report is not even so
> much - as I said before, it should generate about 2-3 pages in pdf.
> We have more than 200 reports working fine, none of them complained about
> large nvarchar fields.
> Did anybody have this type of problem ?
> Please help !
> Thank you,
> Andrei.
>