Access denied and no files...

I performed an install of SSRS and SharePoint as noted in this document...
http://blogs.msdn.com/sharepoint/archive/2007/08/02/microsoft-sql-server-reporting-services-installation-and-configuration-guide-for-sharepoint-integration-mode.aspx
...with one exception I installed everything (SQL Server, Reporting
Services, and SharePoint) on the same server (single server install, don't
worry it is purely a dev box on an isolate test network, I would never do
this in production). I have rebuilt the server twice and worked though this
document each time.
Every time I get to Step 12 (on page 38-39 of the document), I try opening
the reporting services web site using the server name (e.g.
http://servername:8080/Reportserver). I get a login prompt and access denied
after three attempts. When I try to access it through localhost (e.g.
http://localhost:8080/ReportServer), I do not get the login prompt, but I do
get the typical directory browsing page with no files are listed.
All the ACLs (NTFS permissions) are set to allow Full Control for the local
admins and the three accounts being used per the document are in local admins
group. The Local admins group and the three accounts have SysAdmin rights on
SQL server.
I have done many SSRS installs but have yet to experience and issue like
this. I would greatly appreciate any of you pointing me in the right direct
to check settings. Any helpIt sounds like you are running into the Loopback Checking that was put into
place by Windows Server 2003 SP1. Follow the instructions in the KB article
listed below and that should solve your issue.
http://support.microsoft.com/kb/896861
Follow the steps under "Method 1" and see if that works.
Don't forget to reboot for it to kick in.
--
Chris Alton, Microsoft Corp.
SQL Server Developer Support Engineer
This posting is provided "AS IS" with no warranties, and confers no rights.

Absolutely page-bottom alignment on "report footer": Impossible?

Relative newb to SSRS here, but the answer to this question evades me; answers and insight are appreciated.

Report in question is an invoice form. It requires an absolutely bottom-of-page aligned footer that has databound elements.

This is so that whatever page that footer finally appears on will print in such a way that the address will align in a windowed envelope.

Ironically, Books Online gives this exact scenario in explaining headers and footers in SSRS, but they cleverly don't explain how an absolutely bottom-of-page-aligned and data-bound footer can be made to happen. Headers at absolute page top is obviously no problem. Footers at page bottom, not so much.

So, this is not a "page footer"--page footers are employed in the body. Also this footer is databound, so a page footer as it's known in SSRS is out the window anyway.

Most of the time this will print on a single page, but if it breaks to multiple pages, that footer needs to go all the way to the absolute bottom.

I grasp that the "report footer" for SSRS is just what appears at the end of any repeating controls that you've implemented in your body. Because SSRS uses this kind of repeating-control based idiom rather than a section-based idiom as Crystal does, this kind of (what I would consider very basic) positioning control is looking fairly impossible right now.

Among what I've tried:

--Page footer (can't; databound)

--Specifying a page break after the pre-footer controls, and/or a page break before the controls that make up the footer in their properties. This leads to unpredictable results with blank printed pages (as many as 8 for what previews as a 2-page report, how silly is that?).

--Putting in a page-height rectangle as part of the footer (with and without the page breaks mentioned above), with the idea of forcing a basically blank page at the end of the report so that the footer will go to the bottom. SSRS will go ahead and break the page anyway on long elements like that, which again leads to the "footer" being printed in the middle or top of the final page, or whereever it happens to fall.

I may be having to explain to my client that you can't get there from here, and they may have to redesign their report. Does anyone have any insight?

Thank you for your time in reading this.

Hi there Matty,

I think i got the idea that you want to print out the address of the customer at the bottom of the page (ideally the report page footer) but it won't allow you to have any databound values because the databound values are only for the body right ?

If that is the case, there is a common way to get around this.

This is what I do and it does work. Make a couple of textboxes (tb1 and tb2) in the Body of the report. Set the Hidden properties to True for the textboxes.

Next, drag or code into the tb1 and tb2 the dataset values; Name or address or whatever.

In the report footer or page footer, Set your textboxes and named them tbName and tbAddress.

in the expression builder for tbname, put this "=ReportItems!tb1.value" and in tbAddress put "=ReportItems!tb2.value"

When you run the report, tb1 and tb2 will be invisible (you can even send them to the back, hiding behind the table or something, but always make sure that the Hidden property = true). yet your page footer should have the values assigned to them.

I hope this helps and is according to what you are trying to describe.

Bernard Ong

|||

Kind of. The method you describe is pretty much what Books Online says about it. Key to the problem here is that this footer should only appear on the last page, which you get around by examining the page number using hidden fields as you describe, then making it visible as needed.

Problem is, though, that SSRS appears to 'reserve' the space for the header or footer whether it's visible or not, or you've specified Print On Last Page/First Page or not. It just doesn't render elements in that region but it does save the space.

This particular "footer" is literally 1/3 of a portrait page, so I can't have that kind of blank space being held on pages where it's not in use. I've also noticed issues in preview when you have invisible elements in use; although it'll print OK, the display is wildly off.

Very much appreciate your response, though. If you had a workaround up your sleeve for these additional issues with that method, then I'd be golden! :D

|||

As you said, set PrintOnLastPage=true for page footer and then use top padding to print it at the bottom of the page. You can also use expression to set the passing.

Shyam

|||Thank you, but unfortunately that also does not address the space reservation noted above that is critical to this particular use case. Use of the page footer here as the report footer denies it from a differently-formatted use in the report body when it spans pages, and it also causes the space to be reserved on the body pages; this particular report cannot use just 2/3s of the page on every page besides the last one.

Absolutely page-bottom alignment on "report footer": Impossible?

Relative newb to SSRS here, but the answer to this question evades me; answers and insight are appreciated.

Report in question is an invoice form. It requires an absolutely bottom-of-page aligned footer that has databound elements.

This is so that whatever page that footer finally appears on will print in such a way that the address will align in a windowed envelope.

Ironically, Books Online gives this exact scenario in explaining headers and footers in SSRS, but they cleverly don't explain how an absolutely bottom-of-page-aligned and data-bound footer can be made to happen. Headers at absolute page top is obviously no problem. Footers at page bottom, not so much.

So, this is not a "page footer"--page footers are employed in the body. Also this footer is databound, so a page footer as it's known in SSRS is out the window anyway.

Most of the time this will print on a single page, but if it breaks to multiple pages, that footer needs to go all the way to the absolute bottom.

I grasp that the "report footer" for SSRS is just what appears at the end of any repeating controls that you've implemented in your body. Because SSRS uses this kind of repeating-control based idiom rather than a section-based idiom as Crystal does, this kind of (what I would consider very basic) positioning control is looking fairly impossible right now.

Among what I've tried:

--Page footer (can't; databound)

--Specifying a page break after the pre-footer controls, and/or a page break before the controls that make up the footer in their properties. This leads to unpredictable results with blank printed pages (as many as 8 for what previews as a 2-page report, how silly is that?).

--Putting in a page-height rectangle as part of the footer (with and without the page breaks mentioned above), with the idea of forcing a basically blank page at the end of the report so that the footer will go to the bottom. SSRS will go ahead and break the page anyway on long elements like that, which again leads to the "footer" being printed in the middle or top of the final page, or whereever it happens to fall.

I may be having to explain to my client that you can't get there from here, and they may have to redesign their report. Does anyone have any insight?

Thank you for your time in reading this.

Hi there Matty,

I think i got the idea that you want to print out the address of the customer at the bottom of the page (ideally the report page footer) but it won't allow you to have any databound values because the databound values are only for the body right ?

If that is the case, there is a common way to get around this.

This is what I do and it does work. Make a couple of textboxes (tb1 and tb2) in the Body of the report. Set the Hidden properties to True for the textboxes.

Next, drag or code into the tb1 and tb2 the dataset values; Name or address or whatever.

In the report footer or page footer, Set your textboxes and named them tbName and tbAddress.

in the expression builder for tbname, put this "=ReportItems!tb1.value" and in tbAddress put "=ReportItems!tb2.value"

When you run the report, tb1 and tb2 will be invisible (you can even send them to the back, hiding behind the table or something, but always make sure that the Hidden property = true). yet your page footer should have the values assigned to them.

I hope this helps and is according to what you are trying to describe.

Bernard Ong

|||

Kind of. The method you describe is pretty much what Books Online says about it. Key to the problem here is that this footer should only appear on the last page, which you get around by examining the page number using hidden fields as you describe, then making it visible as needed.

Problem is, though, that SSRS appears to 'reserve' the space for the header or footer whether it's visible or not, or you've specified Print On Last Page/First Page or not. It just doesn't render elements in that region but it does save the space.

This particular "footer" is literally 1/3 of a portrait page, so I can't have that kind of blank space being held on pages where it's not in use. I've also noticed issues in preview when you have invisible elements in use; although it'll print OK, the display is wildly off.

Very much appreciate your response, though. If you had a workaround up your sleeve for these additional issues with that method, then I'd be golden! :D

|||

As you said, set PrintOnLastPage=true for page footer and then use top padding to print it at the bottom of the page. You can also use expression to set the passing.

Shyam

|||Thank you, but unfortunately that also does not address the space reservation noted above that is critical to this particular use case. Use of the page footer here as the report footer denies it from a differently-formatted use in the report body when it spans pages, and it also causes the space to be reserved on the body pages; this particular report cannot use just 2/3s of the page on every page besides the last one.|||

I too have a business requirement to put 'footers at the bottom' and have found (like a lot of others here) that SSRS doesn't make this easy using the built-in footer section. The real show stopper is that once you declare the size of the footer section at design time, that's what you get on each and every page.

The breakthrough for me was to recognize that footers as I needed them are really report content. When I took that approach, it became a solvable problem involving three items: the preceding content, the offset, and the notes (as I call them so as not to be confused with SSRS footers).

The offset is implemented as a subreport that has an invisible, variable length table. The length of the table is determined by a parameter, cleverly called the 'offset'. The invisible table acts as filler between the preceding content and the notes so that the notes are bottom justified.

The report gets the offset parameter by calling into business logic that uses:

the data for the preceding content,

the data for the notes content,

the page layout, and

the starting position of the preceding content