ReportViewer control FAQ

These are answers to questions I frequently received from early adopters
(TAP customers):
Q: Is the ReportViewer control included in SQL Server 2005?
A: No. Report Server is a component of SQL Server 2005, but the ReportViewer
control is not. ReportViewer is only included in Visual Studio 2005.
Q: Does SQL Server have to be installed in order to use the ReportViewer
control?
A: No. The only dependency of the ReportViewer control is .NET Framework
2.0.
Q: Is a SQL Server license required to use the ReportViewer control?
A: No. The ReportViewer control is freely redistributable. It can work
independently of SQL Server ('local mode') and a SQL Server license is not
required. In remote mode the ReportViewer control talks to a Report Server.
The Report Server does require a SQL Server license.
Q: Does the data for the report have to come from a SQL Server database?
A: No. Data can come from any source. It is the host application's
responsibility to collect data from whatever source it needs to come from,
and supply it to the control in the form of ADO.NET DataTables or a
collection of business objects. The ReportViewer control does not know or
care where the data is coming from.
Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
Server?
A: No. In remote mode the ReportViewer control can only view reports hosted
on a SQL Server 2005 Report Server. Note that this has nothing to do with
where the data for the report can come from. Data for the report can come
from any source, including SQL Server 2000, Oracle, DB2 and non-database
datasources.
Q: Is the ReportViewer control part of the .NET Framework?
A: No. The ReportViewer control is distributed with Visual Studio 2005, but
it is not part of the .NET Framework. The redistributable is packaged as an
msi.
Q: What SKUs of Visual Studio 2005 include ReportViewer?
A: ReportViewer is included in Standard and up. (i.e., all SKUs except
Express.)
Q: What is the difference between RDL and RDLC formats?
A: RDL files are created by the SQL Server 2005 version of Report Designer.
RDLC files are created by the Visual Studio 2005 version of Report Designer.
RDL and RDLC formats have the same XML schema. However, in RDLC files, some
values (such as query text) are allowed to be empty, which means that they
are not immediately ready to be published to a Report Server. The missing
values can be entered by opening the RDLC file using the SQL Server 2005
version of Report Designer. (You have to rename .rdlc to .rdl first.) RDL
files are fully compatible with the ReportViewer control runtime. However,
RDL files do not contain some information that the design-time of the
ReportViewer control depends on for automatically generating data-binding
code. By manually binding data, RDL files can be used in the ReportViewer
control. Note that the ReportViewer control does not contain any logic for
connecting to databases or executing queries. By separating out such logic,
the ReportViewer has been made compatible with all data sources, including
non-database data sources. However this means that when an RDL file is used
by the ReportViewer control, the SQL related information in the RDL file is
simply ignored by the control. It is the host application's responsibility
to connect to databases, execute queries and supply data to the ReportViewer
control in the form of ADO.NET DataTables.
Q: What does the C in RDLC stand for?
A: The C stands for Client-side processing.
Q: Why doesn't the ReportViewer control support parameter prompting in local
mode?
A: The ReportViewer control does not prompt for parameters when in local
mode. It prompts for parameters when it is connected to a Report Server. In
local mode it does not make sense for ReportViewer to prompt for parameters.
The rationale is as follows: The most common use of report parameters is to
pass to queries as values of query parameters. But unlike the Report Server,
the ReportViewer control does not execute queries itself. Rather, queries
are executed by the host application, and the result is passed to the
ReportViewer control. So the ReportViewer control does not have the
opportunity to set query parameters. Applications should take advantage of
the parameterization features of Visual Studio data wizards instead.
Q: Does xls export require Excel to be installed?
A: No. The xls export feature is independent of Excel. Excel is only
required to view the xls file.
Q: What are the limitations of ReportViewer control?
A: Unlike the Report Server the ReportViewer control does not connect to
databases or execute queries. (But Visual Studio can generate code to do
this.) Also, in local mode the only export format available is Excel. (In
remote mode all formats supported by the Report Server are available.) The
ReportViewer control cannot be extended by adding custom renderers or custom
report items. Besides additional export formats, the Report Server offers
better scalability, central storage, management and access control of
reports, caching, subscriptions, etc.
--
Rajeev Karunakaran [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.even if u have sql server 2000 u can installed Reporting Service. And if u
have installed the samples of Reporting service go to this path
C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\Samples\vb\bin
If there is nothing in the bin juss the compile the example u will get
ReportViewer.dll which u can use ur ASpx page to host a Report.|||The sample included in SQL Server 2000 is also called ReportViewer, but it
is not the same as the new ReportViewer controls included in Whidbey.
--
Rajeev Karunakaran [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Deepak" <Deepak@.discussions.microsoft.com> wrote in message
news:3B4664DD-3F76-4868-A3F9-834BE0DB16F1@.microsoft.com...
> even if u have sql server 2000 u can installed Reporting Service. And if u
> have installed the samples of Reporting service go to this path
> C:\Program Files\Microsoft SQL Server\MSSQL\Reporting
> Services\Samples\vb\bin
> If there is nothing in the bin juss the compile the example u will get
> ReportViewer.dll which u can use ur ASpx page to host a Report.
>|||You mentioned below that the Winforms viewer will only support Excel export;
will there be any support for PDF, XML, and CSV when VS2005 Goes live? Also
I was just curious what the reasoning behind supporting these formats on the
server and not on the client? Thanks.
Matt M.
"Rajeev Karunakaran" <rajeevkarunakaran@.online.microsoft.com> wrote in
message news:uI1AdthRFHA.2228@.TK2MSFTNGP12.phx.gbl...
> These are answers to questions I frequently received from early adopters
> (TAP customers):
> Q: Is the ReportViewer control included in SQL Server 2005?
> A: No. Report Server is a component of SQL Server 2005, but the
> ReportViewer control is not. ReportViewer is only included in Visual
> Studio 2005.
> Q: Does SQL Server have to be installed in order to use the ReportViewer
> control?
> A: No. The only dependency of the ReportViewer control is .NET Framework
> 2.0.
> Q: Is a SQL Server license required to use the ReportViewer control?
> A: No. The ReportViewer control is freely redistributable. It can work
> independently of SQL Server ('local mode') and a SQL Server license is not
> required. In remote mode the ReportViewer control talks to a Report
> Server. The Report Server does require a SQL Server license.
> Q: Does the data for the report have to come from a SQL Server database?
> A: No. Data can come from any source. It is the host application's
> responsibility to collect data from whatever source it needs to come from,
> and supply it to the control in the form of ADO.NET DataTables or a
> collection of business objects. The ReportViewer control does not know or
> care where the data is coming from.
> Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
> Server?
> A: No. In remote mode the ReportViewer control can only view reports
> hosted on a SQL Server 2005 Report Server. Note that this has nothing to
> do with where the data for the report can come from. Data for the report
> can come from any source, including SQL Server 2000, Oracle, DB2 and
> non-database datasources.
> Q: Is the ReportViewer control part of the .NET Framework?
> A: No. The ReportViewer control is distributed with Visual Studio 2005,
> but it is not part of the .NET Framework. The redistributable is packaged
> as an msi.
> Q: What SKUs of Visual Studio 2005 include ReportViewer?
> A: ReportViewer is included in Standard and up. (i.e., all SKUs except
> Express.)
> Q: What is the difference between RDL and RDLC formats?
> A: RDL files are created by the SQL Server 2005 version of Report
> Designer. RDLC files are created by the Visual Studio 2005 version of
> Report Designer. RDL and RDLC formats have the same XML schema. However,
> in RDLC files, some values (such as query text) are allowed to be empty,
> which means that they are not immediately ready to be published to a
> Report Server. The missing values can be entered by opening the RDLC file
> using the SQL Server 2005 version of Report Designer. (You have to rename
> .rdlc to .rdl first.) RDL files are fully compatible with the ReportViewer
> control runtime. However, RDL files do not contain some information that
> the design-time of the ReportViewer control depends on for automatically
> generating data-binding code. By manually binding data, RDL files can be
> used in the ReportViewer control. Note that the ReportViewer control does
> not contain any logic for connecting to databases or executing queries. By
> separating out such logic, the ReportViewer has been made compatible with
> all data sources, including non-database data sources. However this means
> that when an RDL file is used by the ReportViewer control, the SQL related
> information in the RDL file is simply ignored by the control. It is the
> host application's responsibility to connect to databases, execute queries
> and supply data to the ReportViewer control in the form of ADO.NET
> DataTables.
> Q: What does the C in RDLC stand for?
> A: The C stands for Client-side processing.
> Q: Why doesn't the ReportViewer control support parameter prompting in
> local mode?
> A: The ReportViewer control does not prompt for parameters when in local
> mode. It prompts for parameters when it is connected to a Report Server.
> In local mode it does not make sense for ReportViewer to prompt for
> parameters. The rationale is as follows: The most common use of report
> parameters is to pass to queries as values of query parameters. But unlike
> the Report Server, the ReportViewer control does not execute queries
> itself. Rather, queries are executed by the host application, and the
> result is passed to the ReportViewer control. So the ReportViewer control
> does not have the opportunity to set query parameters. Applications should
> take advantage of the parameterization features of Visual Studio data
> wizards instead.
> Q: Does xls export require Excel to be installed?
> A: No. The xls export feature is independent of Excel. Excel is only
> required to view the xls file.
> Q: What are the limitations of ReportViewer control?
> A: Unlike the Report Server the ReportViewer control does not connect to
> databases or execute queries. (But Visual Studio can generate code to do
> this.) Also, in local mode the only export format available is Excel. (In
> remote mode all formats supported by the Report Server are available.) The
> ReportViewer control cannot be extended by adding custom renderers or
> custom report items. Besides additional export formats, the Report Server
> offers better scalability, central storage, management and access control
> of reports, caching, subscriptions, etc.
>
> --
> Rajeev Karunakaran [MSFT]
> Microsoft SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>|||When operating in local processing mode (disconnected mode) the ReportViewer
will only export to Excel (even in VS 2005 final product.) When operating in
remote processing mode (connected to Report Server) all formats supported by
the Report Server will be available. Only Excel renderer was included in the
control in order to keep its size small.
--
Rajeev Karunakaran [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Matt Meyer" <mgmeyer@.gmail.com> wrote in message
news:uCYKD80RFHA.3296@.TK2MSFTNGP15.phx.gbl...
> You mentioned below that the Winforms viewer will only support Excel
> export; will there be any support for PDF, XML, and CSV when VS2005 Goes
> live? Also I was just curious what the reasoning behind supporting these
> formats on the server and not on the client? Thanks.
> Matt M.
> "Rajeev Karunakaran" <rajeevkarunakaran@.online.microsoft.com> wrote in
> message news:uI1AdthRFHA.2228@.TK2MSFTNGP12.phx.gbl...
>> These are answers to questions I frequently received from early adopters
>> (TAP customers):
>> Q: Is the ReportViewer control included in SQL Server 2005?
>> A: No. Report Server is a component of SQL Server 2005, but the
>> ReportViewer control is not. ReportViewer is only included in Visual
>> Studio 2005.
>> Q: Does SQL Server have to be installed in order to use the ReportViewer
>> control?
>> A: No. The only dependency of the ReportViewer control is .NET Framework
>> 2.0.
>> Q: Is a SQL Server license required to use the ReportViewer control?
>> A: No. The ReportViewer control is freely redistributable. It can work
>> independently of SQL Server ('local mode') and a SQL Server license is
>> not required. In remote mode the ReportViewer control talks to a Report
>> Server. The Report Server does require a SQL Server license.
>> Q: Does the data for the report have to come from a SQL Server database?
>> A: No. Data can come from any source. It is the host application's
>> responsibility to collect data from whatever source it needs to come
>> from, and supply it to the control in the form of ADO.NET DataTables or a
>> collection of business objects. The ReportViewer control does not know or
>> care where the data is coming from.
>> Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
>> Server?
>> A: No. In remote mode the ReportViewer control can only view reports
>> hosted on a SQL Server 2005 Report Server. Note that this has nothing to
>> do with where the data for the report can come from. Data for the report
>> can come from any source, including SQL Server 2000, Oracle, DB2 and
>> non-database datasources.
>> Q: Is the ReportViewer control part of the .NET Framework?
>> A: No. The ReportViewer control is distributed with Visual Studio 2005,
>> but it is not part of the .NET Framework. The redistributable is packaged
>> as an msi.
>> Q: What SKUs of Visual Studio 2005 include ReportViewer?
>> A: ReportViewer is included in Standard and up. (i.e., all SKUs except
>> Express.)
>> Q: What is the difference between RDL and RDLC formats?
>> A: RDL files are created by the SQL Server 2005 version of Report
>> Designer. RDLC files are created by the Visual Studio 2005 version of
>> Report Designer. RDL and RDLC formats have the same XML schema. However,
>> in RDLC files, some values (such as query text) are allowed to be empty,
>> which means that they are not immediately ready to be published to a
>> Report Server. The missing values can be entered by opening the RDLC file
>> using the SQL Server 2005 version of Report Designer. (You have to rename
>> .rdlc to .rdl first.) RDL files are fully compatible with the
>> ReportViewer control runtime. However, RDL files do not contain some
>> information that the design-time of the ReportViewer control depends on
>> for automatically generating data-binding code. By manually binding data,
>> RDL files can be used in the ReportViewer control. Note that the
>> ReportViewer control does not contain any logic for connecting to
>> databases or executing queries. By separating out such logic, the
>> ReportViewer has been made compatible with all data sources, including
>> non-database data sources. However this means that when an RDL file is
>> used by the ReportViewer control, the SQL related information in the RDL
>> file is simply ignored by the control. It is the host application's
>> responsibility to connect to databases, execute queries and supply data
>> to the ReportViewer control in the form of ADO.NET DataTables.
>> Q: What does the C in RDLC stand for?
>> A: The C stands for Client-side processing.
>> Q: Why doesn't the ReportViewer control support parameter prompting in
>> local mode?
>> A: The ReportViewer control does not prompt for parameters when in local
>> mode. It prompts for parameters when it is connected to a Report Server.
>> In local mode it does not make sense for ReportViewer to prompt for
>> parameters. The rationale is as follows: The most common use of report
>> parameters is to pass to queries as values of query parameters. But
>> unlike the Report Server, the ReportViewer control does not execute
>> queries itself. Rather, queries are executed by the host application, and
>> the result is passed to the ReportViewer control. So the ReportViewer
>> control does not have the opportunity to set query parameters.
>> Applications should take advantage of the parameterization features of
>> Visual Studio data wizards instead.
>> Q: Does xls export require Excel to be installed?
>> A: No. The xls export feature is independent of Excel. Excel is only
>> required to view the xls file.
>> Q: What are the limitations of ReportViewer control?
>> A: Unlike the Report Server the ReportViewer control does not connect to
>> databases or execute queries. (But Visual Studio can generate code to do
>> this.) Also, in local mode the only export format available is Excel. (In
>> remote mode all formats supported by the Report Server are available.)
>> The ReportViewer control cannot be extended by adding custom renderers or
>> custom report items. Besides additional export formats, the Report Server
>> offers better scalability, central storage, management and access control
>> of reports, caching, subscriptions, etc.
>>
>> --
>> Rajeev Karunakaran [MSFT]
>> Microsoft SQL Server Reporting Services
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>|||.PDF (or .MDI would work) export is actually quite important to us. We
currently have a Crystal based solution that runs invoices to PDF for
archival purposes. Just wanted to cast a strong vote for .PDF export.
Thanks!|||"Rajeev Karunakaran" wrote:
> These are answers to questions I frequently received from early adopters
> (TAP customers):
>
> Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
> Server?
> A: No. In remote mode the ReportViewer control can only view reports hosted
> on a SQL Server 2005 Report Server. Note that this has nothing to do with
> where the data for the report can come from. Data for the report can come
> from any source, including SQL Server 2000, Oracle, DB2 and non-database
> datasources.
>
Rajeev,
I just wanted to make sure that this Q/A is referring the Report Server DB
table being the SSRS 2005 version not that it has to actually be installed on
SQL Server 2005? From everything that I have read so far SSRS 2005 can still
have the Report Server and Report Server Temp DBs stored on SQL Server 2000,
or has this now changed?
Thanks,
Steve|||Hi there
Before all, thank you for your clarifying answers about what can an
what cannot be done with the new control
Now I have one more question about the capabilities of this control.
I was wondering if it is possible to use this control for the creatio
of a new web service (which would be a "pocket-size" :-) an
customized clone of the RS web service)
Although I expect that this ussage is not possible, I'd rather want t
hear that from you, to be sure in which direction should we take
Thank you again
Best regards,
Emil Prage|||About the export formats; MS might be willing to do smth about it:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=b5f3f1cf-4614-474e-b423-0fa9c35f09e1
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=7acce9a3-35f5-4f6b-8789-236db4b45a03
Ethem Azun
"Rajeev Karunakaran" wrote:
> When operating in local processing mode (disconnected mode) the ReportViewer
> will only export to Excel (even in VS 2005 final product.) When operating in
> remote processing mode (connected to Report Server) all formats supported by
> the Report Server will be available. Only Excel renderer was included in the
> control in order to keep its size small.
> --
> Rajeev Karunakaran [MSFT]
> Microsoft SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Matt Meyer" <mgmeyer@.gmail.com> wrote in message
> news:uCYKD80RFHA.3296@.TK2MSFTNGP15.phx.gbl...
> > You mentioned below that the Winforms viewer will only support Excel
> > export; will there be any support for PDF, XML, and CSV when VS2005 Goes
> > live? Also I was just curious what the reasoning behind supporting these
> > formats on the server and not on the client? Thanks.
> >
> > Matt M.
> >
> > "Rajeev Karunakaran" <rajeevkarunakaran@.online.microsoft.com> wrote in
> > message news:uI1AdthRFHA.2228@.TK2MSFTNGP12.phx.gbl...
> >> These are answers to questions I frequently received from early adopters
> >> (TAP customers):
> >>
> >> Q: Is the ReportViewer control included in SQL Server 2005?
> >> A: No. Report Server is a component of SQL Server 2005, but the
> >> ReportViewer control is not. ReportViewer is only included in Visual
> >> Studio 2005.
> >>
> >> Q: Does SQL Server have to be installed in order to use the ReportViewer
> >> control?
> >> A: No. The only dependency of the ReportViewer control is .NET Framework
> >> 2.0.
> >>
> >> Q: Is a SQL Server license required to use the ReportViewer control?
> >> A: No. The ReportViewer control is freely redistributable. It can work
> >> independently of SQL Server ('local mode') and a SQL Server license is
> >> not required. In remote mode the ReportViewer control talks to a Report
> >> Server. The Report Server does require a SQL Server license.
> >>
> >> Q: Does the data for the report have to come from a SQL Server database?
> >> A: No. Data can come from any source. It is the host application's
> >> responsibility to collect data from whatever source it needs to come
> >> from, and supply it to the control in the form of ADO.NET DataTables or a
> >> collection of business objects. The ReportViewer control does not know or
> >> care where the data is coming from.
> >>
> >> Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
> >> Server?
> >> A: No. In remote mode the ReportViewer control can only view reports
> >> hosted on a SQL Server 2005 Report Server. Note that this has nothing to
> >> do with where the data for the report can come from. Data for the report
> >> can come from any source, including SQL Server 2000, Oracle, DB2 and
> >> non-database datasources.
> >>
> >> Q: Is the ReportViewer control part of the .NET Framework?
> >> A: No. The ReportViewer control is distributed with Visual Studio 2005,
> >> but it is not part of the .NET Framework. The redistributable is packaged
> >> as an msi.
> >>
> >> Q: What SKUs of Visual Studio 2005 include ReportViewer?
> >> A: ReportViewer is included in Standard and up. (i.e., all SKUs except
> >> Express.)
> >>
> >> Q: What is the difference between RDL and RDLC formats?
> >> A: RDL files are created by the SQL Server 2005 version of Report
> >> Designer. RDLC files are created by the Visual Studio 2005 version of
> >> Report Designer. RDL and RDLC formats have the same XML schema. However,
> >> in RDLC files, some values (such as query text) are allowed to be empty,
> >> which means that they are not immediately ready to be published to a
> >> Report Server. The missing values can be entered by opening the RDLC file
> >> using the SQL Server 2005 version of Report Designer. (You have to rename
> >> .rdlc to .rdl first.) RDL files are fully compatible with the
> >> ReportViewer control runtime. However, RDL files do not contain some
> >> information that the design-time of the ReportViewer control depends on
> >> for automatically generating data-binding code. By manually binding data,
> >> RDL files can be used in the ReportViewer control. Note that the
> >> ReportViewer control does not contain any logic for connecting to
> >> databases or executing queries. By separating out such logic, the
> >> ReportViewer has been made compatible with all data sources, including
> >> non-database data sources. However this means that when an RDL file is
> >> used by the ReportViewer control, the SQL related information in the RDL
> >> file is simply ignored by the control. It is the host application's
> >> responsibility to connect to databases, execute queries and supply data
> >> to the ReportViewer control in the form of ADO.NET DataTables.
> >>
> >> Q: What does the C in RDLC stand for?
> >> A: The C stands for Client-side processing.
> >>
> >> Q: Why doesn't the ReportViewer control support parameter prompting in
> >> local mode?
> >> A: The ReportViewer control does not prompt for parameters when in local
> >> mode. It prompts for parameters when it is connected to a Report Server.
> >> In local mode it does not make sense for ReportViewer to prompt for
> >> parameters. The rationale is as follows: The most common use of report
> >> parameters is to pass to queries as values of query parameters. But
> >> unlike the Report Server, the ReportViewer control does not execute
> >> queries itself. Rather, queries are executed by the host application, and
> >> the result is passed to the ReportViewer control. So the ReportViewer
> >> control does not have the opportunity to set query parameters.
> >> Applications should take advantage of the parameterization features of
> >> Visual Studio data wizards instead.
> >>
> >> Q: Does xls export require Excel to be installed?
> >> A: No. The xls export feature is independent of Excel. Excel is only
> >> required to view the xls file.
> >>
> >> Q: What are the limitations of ReportViewer control?
> >> A: Unlike the Report Server the ReportViewer control does not connect to
> >> databases or execute queries. (But Visual Studio can generate code to do
> >> this.) Also, in local mode the only export format available is Excel. (In
> >> remote mode all formats supported by the Report Server are available.)
> >> The ReportViewer control cannot be extended by adding custom renderers or
> >> custom report items. Besides additional export formats, the Report Server
> >> offers better scalability, central storage, management and access control
> >> of reports, caching, subscriptions, etc.
> >>
> >>
> >>
> >> --
> >> Rajeev Karunakaran [MSFT]
> >> Microsoft SQL Server Reporting Services
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >
> >
>
>|||Hi Rajeev,
is there a document describing the new report viewer available other
than inside Whidbey? I'd be interested to know what it can do that is
new...It's on my list to read about but I don't have Whidbey
yet......(having only just got SQL Server 2005+Dundas 2005 working!!)
Thanks
Peter|||( see http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=72851)
I have a simple parametized report I can make work in a web form, but keep
getting this error in ASP.NET. The odd thing is have not coded anything for
this report. I have simply used the drag & drop objects on to the ASP form,
set the report and ObjectDataSource smart tags. The report is a local report
and the parameters are entered through a couple of dropdown list boxes. The
first time the report shows ok, the next postback the following error shows
up:
Collection was modified after the enumerator was instantiated.
In earlier posts it was stated that this was a bug, resolved in the june
ctp. Ik am however using the august ctp.
What is the status of this bug (if it is one)?
"Rajeev Karunakaran" wrote:
> These are answers to questions I frequently received from early adopters
> (TAP customers):
> Q: Is the ReportViewer control included in SQL Server 2005?
> A: No. Report Server is a component of SQL Server 2005, but the ReportViewer
> control is not. ReportViewer is only included in Visual Studio 2005.
> Q: Does SQL Server have to be installed in order to use the ReportViewer
> control?
> A: No. The only dependency of the ReportViewer control is .NET Framework
> 2.0.
> Q: Is a SQL Server license required to use the ReportViewer control?
> A: No. The ReportViewer control is freely redistributable. It can work
> independently of SQL Server ('local mode') and a SQL Server license is not
> required. In remote mode the ReportViewer control talks to a Report Server.
> The Report Server does require a SQL Server license.
> Q: Does the data for the report have to come from a SQL Server database?
> A: No. Data can come from any source. It is the host application's
> responsibility to collect data from whatever source it needs to come from,
> and supply it to the control in the form of ADO.NET DataTables or a
> collection of business objects. The ReportViewer control does not know or
> care where the data is coming from.
> Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
> Server?
> A: No. In remote mode the ReportViewer control can only view reports hosted
> on a SQL Server 2005 Report Server. Note that this has nothing to do with
> where the data for the report can come from. Data for the report can come
> from any source, including SQL Server 2000, Oracle, DB2 and non-database
> datasources.
> Q: Is the ReportViewer control part of the .NET Framework?
> A: No. The ReportViewer control is distributed with Visual Studio 2005, but
> it is not part of the .NET Framework. The redistributable is packaged as an
> msi.
> Q: What SKUs of Visual Studio 2005 include ReportViewer?
> A: ReportViewer is included in Standard and up. (i.e., all SKUs except
> Express.)
> Q: What is the difference between RDL and RDLC formats?
> A: RDL files are created by the SQL Server 2005 version of Report Designer.
> RDLC files are created by the Visual Studio 2005 version of Report Designer.
> RDL and RDLC formats have the same XML schema. However, in RDLC files, some
> values (such as query text) are allowed to be empty, which means that they
> are not immediately ready to be published to a Report Server. The missing
> values can be entered by opening the RDLC file using the SQL Server 2005
> version of Report Designer. (You have to rename .rdlc to .rdl first.) RDL
> files are fully compatible with the ReportViewer control runtime. However,
> RDL files do not contain some information that the design-time of the
> ReportViewer control depends on for automatically generating data-binding
> code. By manually binding data, RDL files can be used in the ReportViewer
> control. Note that the ReportViewer control does not contain any logic for
> connecting to databases or executing queries. By separating out such logic,
> the ReportViewer has been made compatible with all data sources, including
> non-database data sources. However this means that when an RDL file is used
> by the ReportViewer control, the SQL related information in the RDL file is
> simply ignored by the control. It is the host application's responsibility
> to connect to databases, execute queries and supply data to the ReportViewer
> control in the form of ADO.NET DataTables.
> Q: What does the C in RDLC stand for?
> A: The C stands for Client-side processing.
> Q: Why doesn't the ReportViewer control support parameter prompting in local
> mode?
> A: The ReportViewer control does not prompt for parameters when in local
> mode. It prompts for parameters when it is connected to a Report Server. In
> local mode it does not make sense for ReportViewer to prompt for parameters.
> The rationale is as follows: The most common use of report parameters is to
> pass to queries as values of query parameters. But unlike the Report Server,
> the ReportViewer control does not execute queries itself. Rather, queries
> are executed by the host application, and the result is passed to the
> ReportViewer control. So the ReportViewer control does not have the
> opportunity to set query parameters. Applications should take advantage of
> the parameterization features of Visual Studio data wizards instead.
> Q: Does xls export require Excel to be installed?
> A: No. The xls export feature is independent of Excel. Excel is only
> required to view the xls file.
> Q: What are the limitations of ReportViewer control?
> A: Unlike the Report Server the ReportViewer control does not connect to
> databases or execute queries. (But Visual Studio can generate code to do
> this.) Also, in local mode the only export format available is Excel. (In
> remote mode all formats supported by the Report Server are available.) The
> ReportViewer control cannot be extended by adding custom renderers or custom
> report items. Besides additional export formats, the Report Server offers
> better scalability, central storage, management and access control of
> reports, caching, subscriptions, etc.
>
> --
> Rajeev Karunakaran [MSFT]
> Microsoft SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>|||The bug has been resolved in the RC version. The reportviewer control now
works fine (the things I have tried anyway). This is very reassuring because
this control is the most important one for me. I was a bit concerned that it
had been forgotten.
"hansh" wrote:
> ( see http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=72851)
> I have a simple parametized report I can make work in a web form, but keep
> getting this error in ASP.NET. The odd thing is have not coded anything for
> this report. I have simply used the drag & drop objects on to the ASP form,
> set the report and ObjectDataSource smart tags. The report is a local report
> and the parameters are entered through a couple of dropdown list boxes. The
> first time the report shows ok, the next postback the following error shows
> up:
> Collection was modified after the enumerator was instantiated.
> In earlier posts it was stated that this was a bug, resolved in the june
> ctp. Ik am however using the august ctp.
> What is the status of this bug (if it is one)?
>
> "Rajeev Karunakaran" wrote:
> > These are answers to questions I frequently received from early adopters
> > (TAP customers):
> >
> > Q: Is the ReportViewer control included in SQL Server 2005?
> > A: No. Report Server is a component of SQL Server 2005, but the ReportViewer
> > control is not. ReportViewer is only included in Visual Studio 2005.
> >
> > Q: Does SQL Server have to be installed in order to use the ReportViewer
> > control?
> > A: No. The only dependency of the ReportViewer control is .NET Framework
> > 2.0.
> >
> > Q: Is a SQL Server license required to use the ReportViewer control?
> > A: No. The ReportViewer control is freely redistributable. It can work
> > independently of SQL Server ('local mode') and a SQL Server license is not
> > required. In remote mode the ReportViewer control talks to a Report Server.
> > The Report Server does require a SQL Server license.
> >
> > Q: Does the data for the report have to come from a SQL Server database?
> > A: No. Data can come from any source. It is the host application's
> > responsibility to collect data from whatever source it needs to come from,
> > and supply it to the control in the form of ADO.NET DataTables or a
> > collection of business objects. The ReportViewer control does not know or
> > care where the data is coming from.
> >
> > Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
> > Server?
> > A: No. In remote mode the ReportViewer control can only view reports hosted
> > on a SQL Server 2005 Report Server. Note that this has nothing to do with
> > where the data for the report can come from. Data for the report can come
> > from any source, including SQL Server 2000, Oracle, DB2 and non-database
> > datasources.
> >
> > Q: Is the ReportViewer control part of the .NET Framework?
> > A: No. The ReportViewer control is distributed with Visual Studio 2005, but
> > it is not part of the .NET Framework. The redistributable is packaged as an
> > msi.
> >
> > Q: What SKUs of Visual Studio 2005 include ReportViewer?
> > A: ReportViewer is included in Standard and up. (i.e., all SKUs except
> > Express.)
> >
> > Q: What is the difference between RDL and RDLC formats?
> > A: RDL files are created by the SQL Server 2005 version of Report Designer.
> > RDLC files are created by the Visual Studio 2005 version of Report Designer.
> > RDL and RDLC formats have the same XML schema. However, in RDLC files, some
> > values (such as query text) are allowed to be empty, which means that they
> > are not immediately ready to be published to a Report Server. The missing
> > values can be entered by opening the RDLC file using the SQL Server 2005
> > version of Report Designer. (You have to rename .rdlc to .rdl first.) RDL
> > files are fully compatible with the ReportViewer control runtime. However,
> > RDL files do not contain some information that the design-time of the
> > ReportViewer control depends on for automatically generating data-binding
> > code. By manually binding data, RDL files can be used in the ReportViewer
> > control. Note that the ReportViewer control does not contain any logic for
> > connecting to databases or executing queries. By separating out such logic,
> > the ReportViewer has been made compatible with all data sources, including
> > non-database data sources. However this means that when an RDL file is used
> > by the ReportViewer control, the SQL related information in the RDL file is
> > simply ignored by the control. It is the host application's responsibility
> > to connect to databases, execute queries and supply data to the ReportViewer
> > control in the form of ADO.NET DataTables.
> >
> > Q: What does the C in RDLC stand for?
> > A: The C stands for Client-side processing.
> >
> > Q: Why doesn't the ReportViewer control support parameter prompting in local
> > mode?
> > A: The ReportViewer control does not prompt for parameters when in local
> > mode. It prompts for parameters when it is connected to a Report Server. In
> > local mode it does not make sense for ReportViewer to prompt for parameters.
> > The rationale is as follows: The most common use of report parameters is to
> > pass to queries as values of query parameters. But unlike the Report Server,
> > the ReportViewer control does not execute queries itself. Rather, queries
> > are executed by the host application, and the result is passed to the
> > ReportViewer control. So the ReportViewer control does not have the
> > opportunity to set query parameters. Applications should take advantage of
> > the parameterization features of Visual Studio data wizards instead.
> >
> > Q: Does xls export require Excel to be installed?
> > A: No. The xls export feature is independent of Excel. Excel is only
> > required to view the xls file.
> >
> > Q: What are the limitations of ReportViewer control?
> > A: Unlike the Report Server the ReportViewer control does not connect to
> > databases or execute queries. (But Visual Studio can generate code to do
> > this.) Also, in local mode the only export format available is Excel. (In
> > remote mode all formats supported by the Report Server are available.) The
> > ReportViewer control cannot be extended by adding custom renderers or custom
> > report items. Besides additional export formats, the Report Server offers
> > better scalability, central storage, management and access control of
> > reports, caching, subscriptions, etc.
> >
> >
> >
> > --
> > Rajeev Karunakaran [MSFT]
> > Microsoft SQL Server Reporting Services
> >
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> >
> >
> >|||http://www.gotreportviewer.com/
"hansh" wrote:
> The bug has been resolved in the RC version. The reportviewer control now
> works fine (the things I have tried anyway). This is very reassuring because
> this control is the most important one for me. I was a bit concerned that it
> had been forgotten.
>
> "hansh" wrote:
> > ( see http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=72851)
> > I have a simple parametized report I can make work in a web form, but keep
> > getting this error in ASP.NET. The odd thing is have not coded anything for
> > this report. I have simply used the drag & drop objects on to the ASP form,
> > set the report and ObjectDataSource smart tags. The report is a local report
> > and the parameters are entered through a couple of dropdown list boxes. The
> > first time the report shows ok, the next postback the following error shows
> > up:
> >
> > Collection was modified after the enumerator was instantiated.
> >
> > In earlier posts it was stated that this was a bug, resolved in the june
> > ctp. Ik am however using the august ctp.
> >
> > What is the status of this bug (if it is one)?
> >
> >
> >
> > "Rajeev Karunakaran" wrote:
> >
> > > These are answers to questions I frequently received from early adopters
> > > (TAP customers):
> > >
> > > Q: Is the ReportViewer control included in SQL Server 2005?
> > > A: No. Report Server is a component of SQL Server 2005, but the ReportViewer
> > > control is not. ReportViewer is only included in Visual Studio 2005.
> > >
> > > Q: Does SQL Server have to be installed in order to use the ReportViewer
> > > control?
> > > A: No. The only dependency of the ReportViewer control is .NET Framework
> > > 2.0.
> > >
> > > Q: Is a SQL Server license required to use the ReportViewer control?
> > > A: No. The ReportViewer control is freely redistributable. It can work
> > > independently of SQL Server ('local mode') and a SQL Server license is not
> > > required. In remote mode the ReportViewer control talks to a Report Server.
> > > The Report Server does require a SQL Server license.
> > >
> > > Q: Does the data for the report have to come from a SQL Server database?
> > > A: No. Data can come from any source. It is the host application's
> > > responsibility to collect data from whatever source it needs to come from,
> > > and supply it to the control in the form of ADO.NET DataTables or a
> > > collection of business objects. The ReportViewer control does not know or
> > > care where the data is coming from.
> > >
> > > Q: Can the ReportViewer view reports hosted on a SQL Server 2000 Report
> > > Server?
> > > A: No. In remote mode the ReportViewer control can only view reports hosted
> > > on a SQL Server 2005 Report Server. Note that this has nothing to do with
> > > where the data for the report can come from. Data for the report can come
> > > from any source, including SQL Server 2000, Oracle, DB2 and non-database
> > > datasources.
> > >
> > > Q: Is the ReportViewer control part of the .NET Framework?
> > > A: No. The ReportViewer control is distributed with Visual Studio 2005, but
> > > it is not part of the .NET Framework. The redistributable is packaged as an
> > > msi.
> > >
> > > Q: What SKUs of Visual Studio 2005 include ReportViewer?
> > > A: ReportViewer is included in Standard and up. (i.e., all SKUs except
> > > Express.)
> > >
> > > Q: What is the difference between RDL and RDLC formats?
> > > A: RDL files are created by the SQL Server 2005 version of Report Designer.
> > > RDLC files are created by the Visual Studio 2005 version of Report Designer.
> > > RDL and RDLC formats have the same XML schema. However, in RDLC files, some
> > > values (such as query text) are allowed to be empty, which means that they
> > > are not immediately ready to be published to a Report Server. The missing
> > > values can be entered by opening the RDLC file using the SQL Server 2005
> > > version of Report Designer. (You have to rename .rdlc to .rdl first.) RDL
> > > files are fully compatible with the ReportViewer control runtime. However,
> > > RDL files do not contain some information that the design-time of the
> > > ReportViewer control depends on for automatically generating data-binding
> > > code. By manually binding data, RDL files can be used in the ReportViewer
> > > control. Note that the ReportViewer control does not contain any logic for
> > > connecting to databases or executing queries. By separating out such logic,
> > > the ReportViewer has been made compatible with all data sources, including
> > > non-database data sources. However this means that when an RDL file is used
> > > by the ReportViewer control, the SQL related information in the RDL file is
> > > simply ignored by the control. It is the host application's responsibility
> > > to connect to databases, execute queries and supply data to the ReportViewer
> > > control in the form of ADO.NET DataTables.
> > >
> > > Q: What does the C in RDLC stand for?
> > > A: The C stands for Client-side processing.
> > >
> > > Q: Why doesn't the ReportViewer control support parameter prompting in local
> > > mode?
> > > A: The ReportViewer control does not prompt for parameters when in local
> > > mode. It prompts for parameters when it is connected to a Report Server. In
> > > local mode it does not make sense for ReportViewer to prompt for parameters.
> > > The rationale is as follows: The most common use of report parameters is to
> > > pass to queries as values of query parameters. But unlike the Report Server,
> > > the ReportViewer control does not execute queries itself. Rather, queries
> > > are executed by the host application, and the result is passed to the
> > > ReportViewer control. So the ReportViewer control does not have the
> > > opportunity to set query parameters. Applications should take advantage of
> > > the parameterization features of Visual Studio data wizards instead.
> > >
> > > Q: Does xls export require Excel to be installed?
> > > A: No. The xls export feature is independent of Excel. Excel is only
> > > required to view the xls file.
> > >
> > > Q: What are the limitations of ReportViewer control?
> > > A: Unlike the Report Server the ReportViewer control does not connect to
> > > databases or execute queries. (But Visual Studio can generate code to do
> > > this.) Also, in local mode the only export format available is Excel. (In
> > > remote mode all formats supported by the Report Server are available.) The
> > > ReportViewer control cannot be extended by adding custom renderers or custom
> > > report items. Besides additional export formats, the Report Server offers
> > > better scalability, central storage, management and access control of
> > > reports, caching, subscriptions, etc.
> > >
> > >
> > >
> > > --
> > > Rajeev Karunakaran [MSFT]
> > > Microsoft SQL Server Reporting Services
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > >
> > >
> > >|||> Q: Is the ReportViewer control part of the .NET Framework?
> A: No. The ReportViewer control is distributed with Visual Studio 2005, but
> it is not part of the .NET Framework. The redistributable is packaged as an
> msi.
I have yet to see a redistributable packaged as an MSI. The only
redistributable available is ReportViewer.exe available at
http://www.microsoft.com/downloads/details.aspx?FamilyID=8a166cac-758d-45c8-b637-dd7726e61367&DisplayLang=en
Redistribution of an MSI will be much easier for my IT department. Are
there any plans to have an MSI instead of an exe installation?sql