Report wizard format templates

Are the style templates offered by the Report Wizard accessible somewhere? Can I add my own standard templates (beyond the bold, casual, corporate, etc.)?
Thanks,
Warren ThornthwaiteStyle definitions be found in %Program Files%\Microsoft SQL
Server\80\Tools\Report Designer\Business Intelligence
Wizards\Reports\Styles\<Language> folders.
You can add your own style and it should be picked by report wizard.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"_WT_" <WT@.discussions.microsoft.com> wrote in message
news:13C29E40-8EB8-437D-8374-3F5B94C2C1F9@.microsoft.com...
> Are the style templates offered by the Report Wizard accessible somewhere?
> Can I add my own standard templates (beyond the bold, casual, corporate,
> etc.)?
> Thanks,
> Warren Thornthwaitesql

report viewer vs SOAP API

The situation is... I have written my own little "report viewer" using the
SOAP API, but it renders slower than the report viewer, and paging (i've
tried both the "count <HR> then rerender" method, as well as the hidden text
field method) is a real pain in the butt. The reason why I've gone with the
SOAP API is for security purposes... I don't want to open the report server
for anonymous access... using the SOAP API i can control security calls and
logons.
After reading around a little, I began to wonder if perhaps the report
viewer could be inserted into a page... use URL access, but still have
network credentials (or RS.LogonUser) accompany it to call the report. In
that regard, I keep all the functionality of the report viewer/URL access,
but still have my security.
Has anybody ran into this, or have suggestions how to go about doing this?
Also... isn't there a way--using the report caching options--to have it
render all the pages, and anytime somebody calls the next page via the SOAP
API, it doesn't have to rerender, but rather, grabs a cached copy of that
page?
Thanks,
--
FooberFoober,
I believe your idea of wrapping the report viewer inside an application that
calls RS.LogonUser first and then if it is successful uses URL access would
work fine. I haven't done it exactly that way, but my application requires
the user to logon to it and then once it does I use URL access with an
embedded IE control to render the reports. Using RS.LogonUser would supplant
my custom login code.
I'm not too clear on your second question, but if a report is setup to cache
its execution for a specific period of time, by altering the
properties->execution settings of the report to cache its execution, the
whole report should be cached, not just a page that has been viewed. My
belief is that because you're implementing paging yourself through the
methods you described, you are circumventing the cached report and
rerendering it somehow. I'm not too sure how you're accomplishing this, but
with URL Access I can tell you it isn't a problem. I guess using the SOAP
API is treating the paging differently.
Hope this helps.
- Joel
"Foober" <Foober@.discussions.microsoft.com> wrote in message
news:67CAA176-55FE-4E18-9E64-48C23FBB960B@.microsoft.com...
> The situation is... I have written my own little "report viewer" using the
> SOAP API, but it renders slower than the report viewer, and paging (i've
> tried both the "count <HR> then rerender" method, as well as the hidden
> text
> field method) is a real pain in the butt. The reason why I've gone with
> the
> SOAP API is for security purposes... I don't want to open the report
> server
> for anonymous access... using the SOAP API i can control security calls
> and
> logons.
> After reading around a little, I began to wonder if perhaps the report
> viewer could be inserted into a page... use URL access, but still have
> network credentials (or RS.LogonUser) accompany it to call the report. In
> that regard, I keep all the functionality of the report viewer/URL access,
> but still have my security.
> Has anybody ran into this, or have suggestions how to go about doing this?
> Also... isn't there a way--using the report caching options--to have it
> render all the pages, and anytime somebody calls the next page via the
> SOAP
> API, it doesn't have to rerender, but rather, grabs a cached copy of that
> page?
> Thanks,
> --
> Foober|||Joel,
I'll definitely have to try doing that (RS.LogonUser matched up with RS
reportViewer); just by being able to bounce that off of somebody else gives
me a little more pep towards trying it... of course, i'll leave my own
reportviewer that I wrote intact.
Re: caching... I realize I didn't word that question very well. I went
directly into the report server and went to a particularly large report,
turned on caching directly there, and then ran the report. Report takes ~3
minutes to render (HUGE, nasty query) but after that, takes ~5 seconds from
page to page (using my viewer) and time between pages is negligible using the
built in URL access (under the report server itself). Caching is definitely
a necessity for what i'm doing... so I just need to read up on how to enable
it via the SOAP calls... (reason why I need to do it via SOAP calls is i
wrote a dynamic report generator that generates the RDL and follows through
to publish the report via SOAP calls);
Re: paging in SOAP... unfortunately it doesn't provide an "Easy" way to
determine how many pages a report contains, etc; you actually have to render
the entire report, then count the number of <HR> in the result stream...
that'll give you page count. You then proceed to rerender only page 1 to
start, then let user change pages as necessary. Another method to acquire
pages via the SOAP is to provide an actual textbox or something in the report
header or footer that has GLOBALS!PageNumber (or whatever the heck it is)...
you could render page 1, pull that down, and then let user change pages
afterwards. Either way it is only a difference of microseconds (time to
parse the result stream) between the two methods... especially if caching is
enabled (thanks for the thought concerning that--glad to know it caches
entire report and not only the page that had been viewed).
--
Foober
"Joel Rumerman" wrote:
> Foober,
> I believe your idea of wrapping the report viewer inside an application that
> calls RS.LogonUser first and then if it is successful uses URL access would
> work fine. I haven't done it exactly that way, but my application requires
> the user to logon to it and then once it does I use URL access with an
> embedded IE control to render the reports. Using RS.LogonUser would supplant
> my custom login code.
> I'm not too clear on your second question, but if a report is setup to cache
> its execution for a specific period of time, by altering the
> properties->execution settings of the report to cache its execution, the
> whole report should be cached, not just a page that has been viewed. My
> belief is that because you're implementing paging yourself through the
> methods you described, you are circumventing the cached report and
> rerendering it somehow. I'm not too sure how you're accomplishing this, but
> with URL Access I can tell you it isn't a problem. I guess using the SOAP
> API is treating the paging differently.
> Hope this helps.
> - Joel
>
> "Foober" <Foober@.discussions.microsoft.com> wrote in message
> news:67CAA176-55FE-4E18-9E64-48C23FBB960B@.microsoft.com...
> > The situation is... I have written my own little "report viewer" using the
> > SOAP API, but it renders slower than the report viewer, and paging (i've
> > tried both the "count <HR> then rerender" method, as well as the hidden
> > text
> > field method) is a real pain in the butt. The reason why I've gone with
> > the
> > SOAP API is for security purposes... I don't want to open the report
> > server
> > for anonymous access... using the SOAP API i can control security calls
> > and
> > logons.
> >
> > After reading around a little, I began to wonder if perhaps the report
> > viewer could be inserted into a page... use URL access, but still have
> > network credentials (or RS.LogonUser) accompany it to call the report. In
> > that regard, I keep all the functionality of the report viewer/URL access,
> > but still have my security.
> >
> > Has anybody ran into this, or have suggestions how to go about doing this?
> >
> > Also... isn't there a way--using the report caching options--to have it
> > render all the pages, and anytime somebody calls the next page via the
> > SOAP
> > API, it doesn't have to rerender, but rather, grabs a cached copy of that
> > page?
> >
> > Thanks,
> >
> > --
> > Foober
>
>|||Doesn't seem like I can get that to work... however, the caching made a huge
difference in load time.
I've decided that to cut down on initial render time I'm going to use
snapshotting. Our clients don't need a 100% live report, so I'll write a
little snapshot client that will accept their requests to view a report, run
the CreateReportHistorySnapshot or BeginUpdateReportExecutionSnapshot
method... (probably the latter in order to call it asynchronously) and once
it is completed, return a link to the user that will load it into my report
viewer.
--
Foober
"Foober" wrote:
> Joel,
> I'll definitely have to try doing that (RS.LogonUser matched up with RS
> reportViewer); just by being able to bounce that off of somebody else gives
> me a little more pep towards trying it... of course, i'll leave my own
> reportviewer that I wrote intact.
> Re: caching... I realize I didn't word that question very well. I went
> directly into the report server and went to a particularly large report,
> turned on caching directly there, and then ran the report. Report takes ~3
> minutes to render (HUGE, nasty query) but after that, takes ~5 seconds from
> page to page (using my viewer) and time between pages is negligible using the
> built in URL access (under the report server itself). Caching is definitely
> a necessity for what i'm doing... so I just need to read up on how to enable
> it via the SOAP calls... (reason why I need to do it via SOAP calls is i
> wrote a dynamic report generator that generates the RDL and follows through
> to publish the report via SOAP calls);
> Re: paging in SOAP... unfortunately it doesn't provide an "Easy" way to
> determine how many pages a report contains, etc; you actually have to render
> the entire report, then count the number of <HR> in the result stream...
> that'll give you page count. You then proceed to rerender only page 1 to
> start, then let user change pages as necessary. Another method to acquire
> pages via the SOAP is to provide an actual textbox or something in the report
> header or footer that has GLOBALS!PageNumber (or whatever the heck it is)...
> you could render page 1, pull that down, and then let user change pages
> afterwards. Either way it is only a difference of microseconds (time to
> parse the result stream) between the two methods... especially if caching is
> enabled (thanks for the thought concerning that--glad to know it caches
> entire report and not only the page that had been viewed).
> --
> Foober
>
> "Joel Rumerman" wrote:
> > Foober,
> >
> > I believe your idea of wrapping the report viewer inside an application that
> > calls RS.LogonUser first and then if it is successful uses URL access would
> > work fine. I haven't done it exactly that way, but my application requires
> > the user to logon to it and then once it does I use URL access with an
> > embedded IE control to render the reports. Using RS.LogonUser would supplant
> > my custom login code.
> >
> > I'm not too clear on your second question, but if a report is setup to cache
> > its execution for a specific period of time, by altering the
> > properties->execution settings of the report to cache its execution, the
> > whole report should be cached, not just a page that has been viewed. My
> > belief is that because you're implementing paging yourself through the
> > methods you described, you are circumventing the cached report and
> > rerendering it somehow. I'm not too sure how you're accomplishing this, but
> > with URL Access I can tell you it isn't a problem. I guess using the SOAP
> > API is treating the paging differently.
> >
> > Hope this helps.
> >
> > - Joel
> >
> >
> > "Foober" <Foober@.discussions.microsoft.com> wrote in message
> > news:67CAA176-55FE-4E18-9E64-48C23FBB960B@.microsoft.com...
> > > The situation is... I have written my own little "report viewer" using the
> > > SOAP API, but it renders slower than the report viewer, and paging (i've
> > > tried both the "count <HR> then rerender" method, as well as the hidden
> > > text
> > > field method) is a real pain in the butt. The reason why I've gone with
> > > the
> > > SOAP API is for security purposes... I don't want to open the report
> > > server
> > > for anonymous access... using the SOAP API i can control security calls
> > > and
> > > logons.
> > >
> > > After reading around a little, I began to wonder if perhaps the report
> > > viewer could be inserted into a page... use URL access, but still have
> > > network credentials (or RS.LogonUser) accompany it to call the report. In
> > > that regard, I keep all the functionality of the report viewer/URL access,
> > > but still have my security.
> > >
> > > Has anybody ran into this, or have suggestions how to go about doing this?
> > >
> > > Also... isn't there a way--using the report caching options--to have it
> > > render all the pages, and anytime somebody calls the next page via the
> > > SOAP
> > > API, it doesn't have to rerender, but rather, grabs a cached copy of that
> > > page?
> > >
> > > Thanks,
> > >
> > > --
> > > Foober
> >
> >
> >

report viewer and reporting services security

i have a web application in studio 2005 using the report viewer control. i have my own security model implemented on my web pages for clients [1..n] each of the [1..n] clients should be able to view reports of their order history. i have the report viewer set up in url mode. the question is that when i have drill downs in my final reports, a user with some tech knowledge, would be able to obtain the url to my sql server running reporting services.

the sql server will not be given a port 80 acess. how do i go about displaying reports without any savvy user being able to locate the server locations/credentials?

i donot want to create windows account for each [1..n] clients as this is ever growing

If by "url mode" you mean hyperlinks pointing to the report URL address, you should rethink your approach. Instead, consider server-side report generation. In this case, SSRS does reasonable job to protect the parameters as you can see by inspecting the drilldown hyperlinks.|||

Teo, thats what i mean. How would i go about the approach that you are suggesting?

- would i have to create subscriptions to generate the reports and save them to disk?

\

|||If i am to use SOAP then the interactive features are not availabe as this read up provides that info:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvb04/html/vb04k8.asp|||You will host the VS.NET 2005 ReportViewer control on your ASP.NET page and bind it to the server report. If you are new to the Report Viewer control, you may find the following article useful.|||I did read the article but from read ups, the drill down interactive feature is lost when using SOA/web services to gerenate report in 'remote mode'. is that statetment true? if not then i guess this would work out well|||This is incorrect. SSRS 2005 enhances the web service APIs to support interactive features so interactive featues will work with the VS.NET ReportViewer.

Report Server database advice

Hi,
is there likely to be any problem with us adding our own custom tables and
stored procedures to the report server database?
We will not be modifying any of the existing objects. Our objects are just
to add some of our own functionality.
thanks
MattI have tried it once.
Didnt have any problems with that!
>--Original Message--
>Hi,
>is there likely to be any problem with us adding our own
custom tables and
>stored procedures to the report server database?
>We will not be modifying any of the existing objects. Our
objects are just
>to add some of our own functionality.
>thanks
>Matt
>
>.
>|||There should be no problem with doing this. The only issue you could run
into is if an upgrade of RS uses a table or SP with the same name. If you
make your names unique enough, there should be no issues.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ravi" <ravikantkv@.rediffmail.com> wrote in message
news:7f8b01c495a1$5d4f7c20$a601280a@.phx.gbl...
> I have tried it once.
> Didnt have any problems with that!
> >--Original Message--
> >Hi,
> >
> >is there likely to be any problem with us adding our own
> custom tables and
> >stored procedures to the report server database?
> >
> >We will not be modifying any of the existing objects. Our
> objects are just
> >to add some of our own functionality.
> >
> >thanks
> >
> >Matt
> >
> >
> >.
> >