Reporting Services 2005 on Windows 2000 SP4 Domain Controller

Hi all,

I'm experiencing a problem with Reporting Services 2005 running on a Windows 2000 AD Domain Controller.

Installation has been done correctly, SQL 2005 and SSRS 2005 are running correctly (I've followed Microsoft KB911846 to solve the "not dtarting after installation" problem).

Accessing reports virtual folder (http://machinename/reports) from localhost, logged on with user Administrator Report Builder option displays correctly. Also accessing from LAN, but with user Administrator, displys Report Builder Option.

Report Builder button is not displayed with other users (i.e. user Dave)

I've given user Dave same permission as Administrator (Content Manager, in SSRS) but Report Buildr still can't be viewed.

If it can be userful to understand this strange behaviour, looking in "Reporting Services Configuration" tool I can see that Web Service Identity is reported as Not configured, with a beautiful red X besides.

Can someone please help me?

Thank you very much for any suggestion.

Regards,

Dave

Solved! :-)

Just had to set domain users as "System Users" in Report Server Management

Dave

Reporting Services 2005 & Parameters

Hi, I experiencing some problems when accesing the Parameters collection on
the dataset to build the the sql statement.
Below is my code (very simple):
DataSet:
="SELECT 'userid' = '" & code.Parameter("userID", Parameters) & "' FROM
users"
Code:
Public Function Parameter(ByVal field As String, ByRef pars As Object) As
String
return pars(field).Value
End Function
This code works just fine on the Preview but if I test the report on the
browser, it doesnt work and returns the following error:
a.. An error has occurred during report processing.
a.. Cannot set the command text for data set 'ExpoMedios'.
a.. Error during processing of the CommandText expression of dataset
'ExpoMedios'.
Doing some debugging the error message inside the function is:
Attempt to access the method failed.
Can anyone pleae explain why this is happening. Your help will be
appreciated.
Regards,
FabianAny help please? It happens when I access to the Parameters Collection
inside a custom code.
Any help will be appreciated.
Thanks in avance,
Fabian von Romberg
"Fabian von Romberg" <fromberg100@.hotmail.com> wrote in message
news:uBbFLro3GHA.3492@.TK2MSFTNGP06.phx.gbl...
> Hi, I experiencing some problems when accesing the Parameters collection
on
> the dataset to build the the sql statement.
> Below is my code (very simple):
> DataSet:
> ="SELECT 'userid' = '" & code.Parameter("userID", Parameters) & "' FROM
> users"
> Code:
> Public Function Parameter(ByVal field As String, ByRef pars As Object) As
> String
> return pars(field).Value
> End Function
>
> This code works just fine on the Preview but if I test the report on the
> browser, it doesnt work and returns the following error:
> a.. An error has occurred during report processing.
> a.. Cannot set the command text for data set 'ExpoMedios'.
> a.. Error during processing of the CommandText expression of dataset
> 'ExpoMedios'.
> Doing some debugging the error message inside the function is:
> Attempt to access the method failed.
>
> Can anyone pleae explain why this is happening. Your help will be
> appreciated.
> Regards,
> Fabian
>

Reporting Services - Local Report - Memory & Session Usage

Hello there, I'm currently experiencing some issues with Reporting
Services' ReportViewer Control. When running the control without a Reporting
Server in 'Local' processing mode we cannot serve very many simultaneous
requests. Worse, if a single user opens several reports one after the other
they can easily get an OutOfMemory exception from the w3wp.exe (Attempting to
serialize something?). I've debugged the page and supporting code and looked
at some output from CLRProfiler with no obvious leaks. I have noticed
something though, after each report is loaded, another ReportHierarchy object
is stored in the user's Session server side. Is the report control storing
the data in session?
-- page code --
...AutoEventWireup="true"....
...
<rsweb:ReportViewer
Width="100%"
runat="server"
AsyncRendering="true"
ShowPrintButton="true"
ShowRefreshButton="false"
ID="<blahblah>"
ShowExportControls="true"
ExportContentDisposition="AlwaysInline">
</rsweb:ReportViewer>
-- page behind code --
reportControl.Reset();
reportControl.ShowPrintButton = true;
reportControl.ShowRefreshButton = false;
reportControl.LocalReport.LoadReportDefinition(<stream>);
reportControl.LocalReport.DisplayName = "My Report";
reportControl.LocalReport.DataSources.Clear();
reportControl.LocalReport.DataSources.Add(new
ReportDataSource(ReportDefinitionGenerator.DYNA_DATASET_NAME,
<DataTable>.DefaultView));
reportControl.SizeToReportContent = true;
Cheers
AntonyStill waiting? Any advice? We're looking at changing the design and
moving away from running reports in 'Local' Processing mode but that would
require making a staging area for the data that the Reporting Services Server
could also access.
;(
"Antony" wrote:
> Hello there, I'm currently experiencing some issues with Reporting
> Services' ReportViewer Control. When running the control without a Reporting
> Server in 'Local' processing mode we cannot serve very many simultaneous
> requests. Worse, if a single user opens several reports one after the other
> they can easily get an OutOfMemory exception from the w3wp.exe (Attempting to
> serialize something?). I've debugged the page and supporting code and looked
> at some output from CLRProfiler with no obvious leaks. I have noticed
> something though, after each report is loaded, another ReportHierarchy object
> is stored in the user's Session server side. Is the report control storing
> the data in session?
> -- page code --
> ...AutoEventWireup="true"....
> ...
> <rsweb:ReportViewer
> Width="100%"
> runat="server"
> AsyncRendering="true"
> ShowPrintButton="true"
> ShowRefreshButton="false"
> ID="<blahblah>"
> ShowExportControls="true"
> ExportContentDisposition="AlwaysInline">
> </rsweb:ReportViewer>
> -- page behind code --
> reportControl.Reset();
> reportControl.ShowPrintButton = true;
> reportControl.ShowRefreshButton = false;
> reportControl.LocalReport.LoadReportDefinition(<stream>);
> reportControl.LocalReport.DisplayName = "My Report";
> reportControl.LocalReport.DataSources.Clear();
> reportControl.LocalReport.DataSources.Add(new
> ReportDataSource(ReportDefinitionGenerator.DYNA_DATASET_NAME,
> <DataTable>.DefaultView));
> reportControl.SizeToReportContent = true;
>
> Cheers
> Antony
>|||I looked at doing local reports and decided against it due to a variety of
reasons. One, designing and testing is a lot harder. Subreports are a pain.
Lots more mucking around.
The local report mode is not intended to be a replacement for the server
based product. If it was, then why buy the server (seeing as how the control
comes with VS and does not require any licensing). So, it does not surprise
me that it has limitations under load.
There is a major shift in how you design. You are used to creating the
tablesets, responding to events etc. With the server based product you
design the dataset and let RS get the data. You do not respond to events.
Yes, you can write a data processing extension if you want but it is
non-trivial and I would only go that way if you absolutely must. Otherwise,
in the report definition define the datasets by putting in the SQL or
referring to a stored procedure.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Antony" <alovric@.trialstat.com(do not spam)> wrote in message
news:83063161-C816-4E81-AB16-3CE47C4277C5@.microsoft.com...
> Still waiting? Any advice? We're looking at changing the design and
> moving away from running reports in 'Local' Processing mode but that would
> require making a staging area for the data that the Reporting Services
> Server
> could also access.
> ;(
>
> "Antony" wrote:
>> Hello there, I'm currently experiencing some issues with Reporting
>> Services' ReportViewer Control. When running the control without a
>> Reporting
>> Server in 'Local' processing mode we cannot serve very many simultaneous
>> requests. Worse, if a single user opens several reports one after the
>> other
>> they can easily get an OutOfMemory exception from the w3wp.exe
>> (Attempting to
>> serialize something?). I've debugged the page and supporting code and
>> looked
>> at some output from CLRProfiler with no obvious leaks. I have noticed
>> something though, after each report is loaded, another ReportHierarchy
>> object
>> is stored in the user's Session server side. Is the report control
>> storing
>> the data in session?
>> -- page code --
>> ...AutoEventWireup="true"....
>> ...
>> <rsweb:ReportViewer
>> Width="100%"
>> runat="server"
>> AsyncRendering="true"
>> ShowPrintButton="true"
>> ShowRefreshButton="false"
>> ID="<blahblah>"
>> ShowExportControls="true"
>> ExportContentDisposition="AlwaysInline">
>> </rsweb:ReportViewer>
>> -- page behind code --
>> reportControl.Reset();
>> reportControl.ShowPrintButton = true;
>> reportControl.ShowRefreshButton = false;
>> reportControl.LocalReport.LoadReportDefinition(<stream>);
>> reportControl.LocalReport.DisplayName = "My Report";
>> reportControl.LocalReport.DataSources.Clear();
>> reportControl.LocalReport.DataSources.Add(new
>> ReportDataSource(ReportDefinitionGenerator.DYNA_DATASET_NAME,
>> <DataTable>.DefaultView));
>> reportControl.SizeToReportContent = true;
>>
>> Cheers
>> Antony
>>|||Thanks Bruce, sorry, I just noticed that I didn't reply to you sooner. Do
you know if the persistance of the ReportHierarchy obj in session is
intentional?
Cheers
Antony
--
;)
"Bruce L-C [MVP]" wrote:
> I looked at doing local reports and decided against it due to a variety of
> reasons. One, designing and testing is a lot harder. Subreports are a pain.
> Lots more mucking around.
> The local report mode is not intended to be a replacement for the server
> based product. If it was, then why buy the server (seeing as how the control
> comes with VS and does not require any licensing). So, it does not surprise
> me that it has limitations under load.
> There is a major shift in how you design. You are used to creating the
> tablesets, responding to events etc. With the server based product you
> design the dataset and let RS get the data. You do not respond to events.
> Yes, you can write a data processing extension if you want but it is
> non-trivial and I would only go that way if you absolutely must. Otherwise,
> in the report definition define the datasets by putting in the SQL or
> referring to a stored procedure.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Antony" <alovric@.trialstat.com(do not spam)> wrote in message
> news:83063161-C816-4E81-AB16-3CE47C4277C5@.microsoft.com...
> > Still waiting? Any advice? We're looking at changing the design and
> > moving away from running reports in 'Local' Processing mode but that would
> > require making a staging area for the data that the Reporting Services
> > Server
> > could also access.
> >
> > ;(
> >
> >
> > "Antony" wrote:
> >
> >> Hello there, I'm currently experiencing some issues with Reporting
> >> Services' ReportViewer Control. When running the control without a
> >> Reporting
> >> Server in 'Local' processing mode we cannot serve very many simultaneous
> >> requests. Worse, if a single user opens several reports one after the
> >> other
> >> they can easily get an OutOfMemory exception from the w3wp.exe
> >> (Attempting to
> >> serialize something?). I've debugged the page and supporting code and
> >> looked
> >> at some output from CLRProfiler with no obvious leaks. I have noticed
> >> something though, after each report is loaded, another ReportHierarchy
> >> object
> >> is stored in the user's Session server side. Is the report control
> >> storing
> >> the data in session?
> >>
> >> -- page code --
> >> ...AutoEventWireup="true"....
> >> ...
> >> <rsweb:ReportViewer
> >> Width="100%"
> >> runat="server"
> >> AsyncRendering="true"
> >> ShowPrintButton="true"
> >> ShowRefreshButton="false"
> >> ID="<blahblah>"
> >> ShowExportControls="true"
> >> ExportContentDisposition="AlwaysInline">
> >> </rsweb:ReportViewer>
> >>
> >> -- page behind code --
> >> reportControl.Reset();
> >> reportControl.ShowPrintButton = true;
> >> reportControl.ShowRefreshButton = false;
> >> reportControl.LocalReport.LoadReportDefinition(<stream>);
> >> reportControl.LocalReport.DisplayName = "My Report";
> >> reportControl.LocalReport.DataSources.Clear();
> >> reportControl.LocalReport.DataSources.Add(new
> >> ReportDataSource(ReportDefinitionGenerator.DYNA_DATASET_NAME,
> >> <DataTable>.DefaultView));
> >> reportControl.SizeToReportContent = true;
> >>
> >>
> >> Cheers
> >> Antony
> >>
> >>
>
>|||Were you able to resolve your performance issues when using the ReportViewer
control in Local Mode? If so, what steps did you take?
We are considering doing the same but are concerned about performance
degradation as well.
Thanks for any information you can provide.
"Antony" wrote:
> Thanks Bruce, sorry, I just noticed that I didn't reply to you sooner. Do
> you know if the persistance of the ReportHierarchy obj in session is
> intentional?
> Cheers
> Antony
> --
> ;)
>
> "Bruce L-C [MVP]" wrote:
> > I looked at doing local reports and decided against it due to a variety of
> > reasons. One, designing and testing is a lot harder. Subreports are a pain.
> > Lots more mucking around.
> >
> > The local report mode is not intended to be a replacement for the server
> > based product. If it was, then why buy the server (seeing as how the control
> > comes with VS and does not require any licensing). So, it does not surprise
> > me that it has limitations under load.
> >
> > There is a major shift in how you design. You are used to creating the
> > tablesets, responding to events etc. With the server based product you
> > design the dataset and let RS get the data. You do not respond to events.
> > Yes, you can write a data processing extension if you want but it is
> > non-trivial and I would only go that way if you absolutely must. Otherwise,
> > in the report definition define the datasets by putting in the SQL or
> > referring to a stored procedure.
> >
> >
> > --
> > Bruce Loehle-Conger
> > MVP SQL Server Reporting Services
> >
> > "Antony" <alovric@.trialstat.com(do not spam)> wrote in message
> > news:83063161-C816-4E81-AB16-3CE47C4277C5@.microsoft.com...
> > > Still waiting? Any advice? We're looking at changing the design and
> > > moving away from running reports in 'Local' Processing mode but that would
> > > require making a staging area for the data that the Reporting Services
> > > Server
> > > could also access.
> > >
> > > ;(
> > >
> > >
> > > "Antony" wrote:
> > >
> > >> Hello there, I'm currently experiencing some issues with Reporting
> > >> Services' ReportViewer Control. When running the control without a
> > >> Reporting
> > >> Server in 'Local' processing mode we cannot serve very many simultaneous
> > >> requests. Worse, if a single user opens several reports one after the
> > >> other
> > >> they can easily get an OutOfMemory exception from the w3wp.exe
> > >> (Attempting to
> > >> serialize something?). I've debugged the page and supporting code and
> > >> looked
> > >> at some output from CLRProfiler with no obvious leaks. I have noticed
> > >> something though, after each report is loaded, another ReportHierarchy
> > >> object
> > >> is stored in the user's Session server side. Is the report control
> > >> storing
> > >> the data in session?
> > >>
> > >> -- page code --
> > >> ...AutoEventWireup="true"....
> > >> ...
> > >> <rsweb:ReportViewer
> > >> Width="100%"
> > >> runat="server"
> > >> AsyncRendering="true"
> > >> ShowPrintButton="true"
> > >> ShowRefreshButton="false"
> > >> ID="<blahblah>"
> > >> ShowExportControls="true"
> > >> ExportContentDisposition="AlwaysInline">
> > >> </rsweb:ReportViewer>
> > >>
> > >> -- page behind code --
> > >> reportControl.Reset();
> > >> reportControl.ShowPrintButton = true;
> > >> reportControl.ShowRefreshButton = false;
> > >> reportControl.LocalReport.LoadReportDefinition(<stream>);
> > >> reportControl.LocalReport.DisplayName = "My Report";
> > >> reportControl.LocalReport.DataSources.Clear();
> > >> reportControl.LocalReport.DataSources.Add(new
> > >> ReportDataSource(ReportDefinitionGenerator.DYNA_DATASET_NAME,
> > >> <DataTable>.DefaultView));
> > >> reportControl.SizeToReportContent = true;
> > >>
> > >>
> > >> Cheers
> > >> Antony
> > >>
> > >>
> >
> >
> >