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 server viewer renders incorrectly but exporting yields correct output!

I have a rather complicated report with lots and lots of textbox and line controls. When I preview the report on the Report Server the layout is all kinds of skewed and all kinds of stuff is out of place. But when I export the report to PDF or TIFF, the output reverts to it's proper form. Why is it doing this? Is there anything that I can do to not make it so ugly when previewing?

Does it seem like there are line feeds where there really shouldn't be? Try changing the width of your report.

|||

The line controls have been an issue for me. In my layout I have a couple of lines that extend past where they would logically go then when I previewed in VS the line would be well short of where I wanted, and then when I exported out to PDF it rendered fine. Now I am loading the reports onto a Report Server and getting an even crazier preview output.

Report Server renders incorrect URL for [Export] button

Good day,
We have a Report Server 2000 on a client site. The server is accessible
via server name (NetBIOS name) from the local LAN, but only via a DNS name
from outer regions of the WAN (these users are on a different but trusted
domain in the bigger forest). The reports render successfully when accessed
via either the NetBIOS or DNS name, but the URL rendered for the â'Exportâ'
functionality always refers to the NetBIOS (server) name. As a result users
on the WAN cannot use the â'Exportâ' functionality since the URL is not found
from that network location (without us adding a local host entry which is
against company policy).
The page source shows a number of variables, including dmRepUrl,
touchSessionUrl, printUrl, renderingUrl, exportUrl and docMapUrl â' these are
all incorrectly mapping to the server name.
I cannot find any matching entry in the Report Server configuration and it
seems as-if this code is output by a compiled assembly on the Report Server.
Are these URLs configurable at all?
Thank you,
James Avenant
GijimaAst ConsultantHi James,
Thank you for your posting!
From your description, my understanding of this issue is: You want to
deploy your report server on a WAN environment. If I misunderstood your
concern, please feel free to let me know.
Based on my experience, you need to specify a fully qualified domain name
instead of the Netbios name in the config file.
The first step is to change the following two registry values under this
key to the appropriate new values:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\80\Reporting
Services\
RSVirtualDir = http://server.company.com/ReportServer (Old Value was
http://server/ReportServer)
WAVirtualDir = http://server.company.com/Reports (Old Value was
http://server/Reports)
The final piece is to make a change in the following to config files on
your reporting server:
C:\Program Files\Microsoft SQL Server\MSSQL\Reporting
Services\ReportServer\RSReportServer.config
C:\Program Files\Microsoft SQL Server\MSSQL\Reporting
Services\ReportManager\RSWebApplication.config
Each file will contain one instance of the server referenced by name
(http://server/ReportServer). Replace it with the fully qualified domain
name, keeping the trailing directory
(http://server.company.com/ReportServer)
Now just restart the service and you should be able to access the reports
inside or out using a fully qualified domain name.
Hope this will be helpful!
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.

Report Renders w/out parameters being selected

I have a report with a parameter list. The parameter has no default value.
When I open the report it renders without waiting for the parameter to be
selected and the parameter list is empty.
I ran SQL Profiler and the sproc that is used to populate the parameter list
is being run and I verified in Query Analyzer that the sproc is returning 4
values.
This same report runs ok on other environments (I have double checked an
uploaded the same RDL to multiple servers).
Any ideas? Is there a server setting that would control this?Try to delete report from server and re-deploy from report designer.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Joe" <noemail@.noemail.com> wrote in message
news:esAZuAcnFHA.1996@.TK2MSFTNGP10.phx.gbl...
>I have a report with a parameter list. The parameter has no default value.
> When I open the report it renders without waiting for the parameter to be
> selected and the parameter list is empty.
> I ran SQL Profiler and the sproc that is used to populate the parameter
> list is being run and I verified in Query Analyzer that the sproc is
> returning 4 values.
> This same report runs ok on other environments (I have double checked an
> uploaded the same RDL to multiple servers).
> Any ideas? Is there a server setting that would control this?
>

report renders manually; subscription doesn't work

I can manually render and view a report, but my subscription to the same
report fails with this error in the log file:
ReportingServicesService!library!1210!07/19/2005-15:20:55:: e ERROR:
Throwing
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException:
The Report Server has encountered a configuration error; more details in the
log files, AuthzInitializeContextFromSid: Win32 error: 1355;
Info:
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException:
The Report Server has encountered a configuration error; more details in the
log files
ReportingServicesService!library!1210!07/19/2005-15:20:55:: i INFO:
Initializing EnableExecutionLogging to 'True' as specified in Server system
properties.
ReportingServicesService!emailextension!1210!07/19/2005-15:20:55:: Error
sending email. Microsoft.ReportingServices.Diagnostics.Utilities.RSException:
The Report Server has encountered a configuration error; more details in the
log files -->
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException:
The Report Server has encountered a configuration error; more details in the
log files
at
Microsoft.ReportingServices.Authorization.Native.GetAuthzContextForUser(IntPtr userSid)
at Microsoft.ReportingServices.Authorization.Native.IsAdmin(String
userName)
at
Microsoft.ReportingServices.Authorization.WindowsAuthorization.IsAdmin(String
userName, IntPtr userToken)
at
Microsoft.ReportingServices.Authorization.WindowsAuthorization.CheckAccess(String
userName, IntPtr userToken, Byte[] secDesc, ReportOperation requiredOperation)
at Microsoft.ReportingServices.Library.Security.CheckAccess(ItemType
catItemType, Byte[] secDesc, ReportOperation rptOper)
at
Microsoft.ReportingServices.Library.RSService._GetReportParameterDefinitionFromCatalog(CatalogItemContext
reportContext, String historyID, Boolean forRendering, Guid& reportID, Int32&
executionOption, String& savedParametersXml, ReportSnapshot&
compiledDefinition, ReportSnapshot& snapshotData, Guid& linkID, DateTime&
historyDate)
at
Microsoft.ReportingServices.Library.RSService._GetReportParameters(String
report, String historyID, Boolean forRendering, NameValueCollection values,
DatasourceCredentialsCollection credentials)
at
Microsoft.ReportingServices.Library.RSService.RenderAsLiveOrSnapshot(CatalogItemContext
reportContext, ClientRequest session, Warning[]& warnings,
ParameterInfoCollection& effectiveParameters)
at
Microsoft.ReportingServices.Library.RSService.RenderFirst(CatalogItemContext
reportContext, ClientRequest session, Warning[]& warnings,
ParameterInfoCollection& effectiveParameters, String[]& secondaryStreamNames)
at Microsoft.ReportingServices.Library.RenderFirstCancelableStep.Execute()
at
Microsoft.ReportingServices.Diagnostics.CancelablePhaseBase.ExecuteWrapper()
-- End of inner exception stack trace --
at
Microsoft.ReportingServices.Diagnostics.CancelablePhaseBase.ExecuteWrapper()
at
Microsoft.ReportingServices.Library.RenderFirstCancelableStep.RenderFirst(RSService
rs, CatalogItemContext reportContext, ClientRequest session, JobTypeEnum
type, Warning[]& warnings, ParameterInfoCollection& effectiveParameters,
String[]& secondaryStreamNames)
at Microsoft.ReportingServices.Library.ReportImpl.Render(String
renderFormat, String deviceInfo)
at
Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider.ConstructMessageBody(IMessage message, Notification notification, SubscriptionData data)
at
Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider.CreateMessage(Notification notification)
at
Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider.Deliver(Notification notification)
ReportingServicesService!notification!1210!07/19/2005-15:20:55::
Notification e07ed229-a912-4843-b66f-fb15c2af2596 completed. Success: False,
Status: Failure sending mail: The Report Server has encountered a
configuration error; more details in the log files, DeliveryExtension: Report
Server Email, Report: <report name>, Attempt 0
I have verified that the SMTP service is working, and there is no
undelivered mail in the mailroot.
Any ideas?
--
Berry Morgan
JSOHi Berry,
Based on my experience, the KB article 834859 probably applies to the issue
related to email delivery on your computer. As mentioined in the KB 834859,
there is a known issue that AuthzInitializeContextFromSid function passes a
non-null-terminated string to the DsGetDcName function. Apparently this
issue potentially cause problems when Reporting Services tries to use this
function.
To resolve this problem immediately, please contact Microsoft Product
Support Services to obtain the hotfix. For a complete list of Microsoft
Product Support Services phone numbers and information about support costs,
visit the following Microsoft Web site:
http://support.microsoft.com/default.aspx?scid=fh;[LN];CNTACTMS
Note In special cases, charges that are ordinarily incurred for support
calls may be canceled if a Microsoft Support Professional determines that a
specific update will resolve your problem. The usual support costs will
apply to additional support questions and issues that do not qualify for
the specific update in question.
You may also want to apply Windows 2003 SP1 which includes this hotfix.
If the issue persists, I suggest that you refer to the following article to
troubleshoot the issue:
842423 A call to the AuthzInitializeContextFromSid API function may fail
during
http://support.microsoft.com/?id=842423
If anything is unclear, feel free to let us know.
Sincerely,
William Wang
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
Business-Critical Phone Support (BCPS) provides you with technical phone
support at no charge during critical LAN outages or "business down"
situations. This benefit is available 24 hours a day, 7 days a week to all
Microsoft technology partners in the United States and Canada.
This and other support options are available here:
BCPS:
https://partner.microsoft.com/US/technicalsupport/supportoverview/40010469
Others: https://partner.microsoft.com/US/technicalsupport/supportoverview/
If you are outside the United States, please visit our International
Support page:
http://support.microsoft.com/default.aspx?scid=%2finternational.aspx.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.