|
|
You're in the
sql server reporting services
group:Render reports WITHOUT using web service?
sql server reporting services:
What do you mean by load reports and render them yourself? Do you mean load
the report definitions or a completed report? Have you looked at the FileRenderSave sample application? Couldn't you render the reports in your own application via the web service and save them to your database? Sorry if I don't understand your issues. [quoted text, click to view] "Damian Cugley" wrote:
> We want to be able to render reports in our web application and > therefore have no need for the folders, roles, permissions system, etc., > supplied by ReportServer: we already have a user database and > permissions system. It would be nice if we could load reports and > render them directly, rather than having to go via a web service, > especially as the web service has to be extended to understand our user > database, and while writing the authentication extension is a trivial > matter (since we already handle authentication), getting ReportServer to > either use the extension or otherwise explain what is wrong is turning > out to be a nightmare exercise in frustration. > > For a stand-alone intranet-bound application where Windows domain > log-ins the ReportServer arrangement makes sense, but for integration in > to existing applications which do not use Windows authentication it > makes Reporting Services a risky proposition at best (risky in the sense > that writing the security extension *might* take one day, or might take > six weeks during which your programmers develop ulcers and quit in > disgust). > > Of course, the DLLs that do the rendering are just sitting there in the > ReportServer directory -- but given that they are even less documented > than the security-extension configuration (and liable to change in > future versions), I don't think I could serious recommend we try to use > them. Pity. > > I don't suppose there are any plans to make the rendering class > libraries available to developers? > >
We had a very similar scenario. We used webservice. crated our RDL using our
custom application. Called Createreport method and loaded the rdl to report server using a common user impersonation. This user has full authority on report server. The report isrendered using the render method and the binary data returned is saved as file to a our custom application folder before delivered to user. I agree with you. It would have been nice if those DLL where programmable. [quoted text, click to view] "Damian Cugley" wrote:
> We want to be able to render reports in our web application and > therefore have no need for the folders, roles, permissions system, etc., > supplied by ReportServer: we already have a user database and > permissions system. It would be nice if we could load reports and > render them directly, rather than having to go via a web service, > especially as the web service has to be extended to understand our user > database, and while writing the authentication extension is a trivial > matter (since we already handle authentication), getting ReportServer to > either use the extension or otherwise explain what is wrong is turning > out to be a nightmare exercise in frustration. > > For a stand-alone intranet-bound application where Windows domain > log-ins the ReportServer arrangement makes sense, but for integration in > to existing applications which do not use Windows authentication it > makes Reporting Services a risky proposition at best (risky in the sense > that writing the security extension *might* take one day, or might take > six weeks during which your programmers develop ulcers and quit in > disgust). > > Of course, the DLLs that do the rendering are just sitting there in the > ReportServer directory -- but given that they are even less documented > than the security-extension configuration (and liable to change in > future versions), I don't think I could serious recommend we try to use > them. Pity. > > I don't suppose there are any plans to make the rendering class > libraries available to developers? > >
Doesn't help you now but this is exactly the scenario that the new web and
winform controls will help. The new controls will work either with or without Report Server. So you could embed the control into your app and provide it with the rdl to use. I believe you will also be able to give it the dataset to use as well. The next beta of Widbey will have these controls (which I believe should be out fairly soon). There will be a go live license with Widbey but not sure if that includes the use of these controls or not. Anyway, once the next beta is out you might want to investigate these controls. -- Bruce Loehle-Conger MVP SQL Server Reporting Services [quoted text, click to view] "vRam" <vRam@discussions.microsoft.com> wrote in message news:E227049A-DBC5-4905-A4EA-BF939567046B@microsoft.com... > We had a very similar scenario. We used webservice. crated our RDL using our > custom application. Called Createreport method and loaded the rdl to report > server using a common user impersonation. This user has full authority on > report server. The report isrendered using the render method and the binary > data returned is saved as file to a our custom application folder before > delivered to user. > > I agree with you. It would have been nice if those DLL where programmable. > > "Damian Cugley" wrote: > > > We want to be able to render reports in our web application and > > therefore have no need for the folders, roles, permissions system, etc., > > supplied by ReportServer: we already have a user database and > > permissions system. It would be nice if we could load reports and > > render them directly, rather than having to go via a web service, > > especially as the web service has to be extended to understand our user > > database, and while writing the authentication extension is a trivial > > matter (since we already handle authentication), getting ReportServer to > > either use the extension or otherwise explain what is wrong is turning > > out to be a nightmare exercise in frustration. > > > > For a stand-alone intranet-bound application where Windows domain > > log-ins the ReportServer arrangement makes sense, but for integration in > > to existing applications which do not use Windows authentication it > > makes Reporting Services a risky proposition at best (risky in the sense > > that writing the security extension *might* take one day, or might take > > six weeks during which your programmers develop ulcers and quit in > > disgust). > > > > Of course, the DLLs that do the rendering are just sitting there in the > > ReportServer directory -- but given that they are even less documented > > than the security-extension configuration (and liable to change in > > future versions), I don't think I could serious recommend we try to use > > them. Pity. > > > > I don't suppose there are any plans to make the rendering class > > libraries available to developers? > > > > > >
We want to be able to render reports in our web application and
therefore have no need for the folders, roles, permissions system, etc., supplied by ReportServer: we already have a user database and permissions system. It would be nice if we could load reports and render them directly, rather than having to go via a web service, especially as the web service has to be extended to understand our user database, and while writing the authentication extension is a trivial matter (since we already handle authentication), getting ReportServer to either use the extension or otherwise explain what is wrong is turning out to be a nightmare exercise in frustration. For a stand-alone intranet-bound application where Windows domain log-ins the ReportServer arrangement makes sense, but for integration in to existing applications which do not use Windows authentication it makes Reporting Services a risky proposition at best (risky in the sense that writing the security extension *might* take one day, or might take six weeks during which your programmers develop ulcers and quit in disgust). Of course, the DLLs that do the rendering are just sitting there in the ReportServer directory -- but given that they are even less documented than the security-extension configuration (and liable to change in future versions), I don't think I could serious recommend we try to use them. Pity. I don't suppose there are any plans to make the rendering class libraries available to developers?
[quoted text, click to view]
IraD wrote: > What do you mean by load reports and render them yourself? Something similar to what you would do via the web service, except not using the web service. Also I would prefer it if Render could take as an argument a stream writer to output to, rather than requiring that the entire results be copied in to memory and out again. Going the web service route expends a lot more CPU cycles and requires more RAM (especially as the PDF file not only is held entirely in memory but is base64-encoded along the way). [quoted text, click to view] > Couldn't you render the reports in your > own application via the web service and save them to your database? Yes, but using the web service gains me nothing and costs me a lot. It is worse if I intend to use a custom user database rather than Windows authentication, in the sense that I still cannot get the web service to
In the "Local" mode, the controls will take a RDL and datasets, and process
and render without the need of a report server. -- Robert This posting is provided "AS IS" with no warranties, and confers no rights. [quoted text, click to view] "Bruce L-C [MVP]" <bruce_lcNOSPAM@hotmail.com> wrote in message news:%234isip4OFHA.3144@tk2msftngp13.phx.gbl... > Doesn't help you now but this is exactly the scenario that the new web and > winform controls will help. The new controls will work either with or > without Report Server. So you could embed the control into your app and > provide it with the rdl to use. I believe you will also be able to give it > the dataset to use as well. The next beta of Widbey will have these > controls > (which I believe should be out fairly soon). There will be a go live > license > with Widbey but not sure if that includes the use of these controls or > not. > Anyway, once the next beta is out you might want to investigate these > controls. > > > -- > Bruce Loehle-Conger > MVP SQL Server Reporting Services > > "vRam" <vRam@discussions.microsoft.com> wrote in message > news:E227049A-DBC5-4905-A4EA-BF939567046B@microsoft.com... >> We had a very similar scenario. We used webservice. crated our RDL using > our >> custom application. Called Createreport method and loaded the rdl to > report >> server using a common user impersonation. This user has full authority on >> report server. The report isrendered using the render method and the > binary >> data returned is saved as file to a our custom application folder before >> delivered to user. >> >> I agree with you. It would have been nice if those DLL where >> programmable. >> >> "Damian Cugley" wrote: >> >> > We want to be able to render reports in our web application and >> > therefore have no need for the folders, roles, permissions system, >> > etc., >> > supplied by ReportServer: we already have a user database and >> > permissions system. It would be nice if we could load reports and >> > render them directly, rather than having to go via a web service, >> > especially as the web service has to be extended to understand our user >> > database, and while writing the authentication extension is a trivial >> > matter (since we already handle authentication), getting ReportServer >> > to >> > either use the extension or otherwise explain what is wrong is turning >> > out to be a nightmare exercise in frustration. >> > >> > For a stand-alone intranet-bound application where Windows domain >> > log-ins the ReportServer arrangement makes sense, but for integration >> > in >> > to existing applications which do not use Windows authentication it >> > makes Reporting Services a risky proposition at best (risky in the >> > sense >> > that writing the security extension *might* take one day, or might take >> > six weeks during which your programmers develop ulcers and quit in >> > disgust). >> > >> > Of course, the DLLs that do the rendering are just sitting there in the >> > ReportServer directory -- but given that they are even less documented >> > than the security-extension configuration (and liable to change in >> > future versions), I don't think I could serious recommend we try to use >> > them. Pity. >> > >> > I don't suppose there are any plans to make the rendering class >> > libraries available to developers? >> > >> > >> > > >
Robert, do you know if the Widbey go-live license will include the controls?
-- Bruce Loehle-Conger MVP SQL Server Reporting Services [quoted text, click to view] "Robert Bruckner [MSFT]" <robruc@online.microsoft.com> wrote in message news:eWSkmSLPFHA.3024@TK2MSFTNGP10.phx.gbl... > In the "Local" mode, the controls will take a RDL and datasets, and process > and render without the need of a report server. > > -- Robert > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "Bruce L-C [MVP]" <bruce_lcNOSPAM@hotmail.com> wrote in message > news:%234isip4OFHA.3144@tk2msftngp13.phx.gbl... > > Doesn't help you now but this is exactly the scenario that the new web and > > winform controls will help. The new controls will work either with or > > without Report Server. So you could embed the control into your app and > > provide it with the rdl to use. I believe you will also be able to give it > > the dataset to use as well. The next beta of Widbey will have these > > controls > > (which I believe should be out fairly soon). There will be a go live > > license > > with Widbey but not sure if that includes the use of these controls or > > not. > > Anyway, once the next beta is out you might want to investigate these > > controls. > > > > > > -- > > Bruce Loehle-Conger > > MVP SQL Server Reporting Services > > > > "vRam" <vRam@discussions.microsoft.com> wrote in message > > news:E227049A-DBC5-4905-A4EA-BF939567046B@microsoft.com... > >> We had a very similar scenario. We used webservice. crated our RDL using > > our > >> custom application. Called Createreport method and loaded the rdl to > > report > >> server using a common user impersonation. This user has full authority on > >> report server. The report isrendered using the render method and the > > binary > >> data returned is saved as file to a our custom application folder before > >> delivered to user. > >> > >> I agree with you. It would have been nice if those DLL where > >> programmable. > >> > >> "Damian Cugley" wrote: > >> > >> > We want to be able to render reports in our web application and > >> > therefore have no need for the folders, roles, permissions system, > >> > etc., > >> > supplied by ReportServer: we already have a user database and > >> > permissions system. It would be nice if we could load reports and > >> > render them directly, rather than having to go via a web service, > >> > especially as the web service has to be extended to understand our user > >> > database, and while writing the authentication extension is a trivial > >> > matter (since we already handle authentication), getting ReportServer > >> > to > >> > either use the extension or otherwise explain what is wrong is turning > >> > out to be a nightmare exercise in frustration. > >> > > >> > For a stand-alone intranet-bound application where Windows domain > >> > log-ins the ReportServer arrangement makes sense, but for integration > >> > in > >> > to existing applications which do not use Windows authentication it > >> > makes Reporting Services a risky proposition at best (risky in the > >> > sense > >> > that writing the security extension *might* take one day, or might take > >> > six weeks during which your programmers develop ulcers and quit in > >> > disgust). > >> > > >> > Of course, the DLLs that do the rendering are just sitting there in the > >> > ReportServer directory -- but given that they are even less documented > >> > than the security-extension configuration (and liable to change in > >> > future versions), I don't think I could serious recommend we try to use > >> > them. Pity. > >> > > >> > I don't suppose there are any plans to make the rendering class > >> > libraries available to developers? > >> > > >> > > >> > > > > > > >
My understanding is that the Whidbey Go-Live license only applies to
selected customers approved for the Whidbey TAP program. In that case, the RS controls are covered. -- This posting is provided "AS IS" with no warranties, and confers no rights. [quoted text, click to view] "Bruce L-C [MVP]" <bruce_lcNOSPAM@hotmail.com> wrote in message news:e$uvgJqPFHA.3156@TK2MSFTNGP15.phx.gbl... > Robert, do you know if the Widbey go-live license will include the > controls? > > -- > Bruce Loehle-Conger > MVP SQL Server Reporting Services > > "Robert Bruckner [MSFT]" <robruc@online.microsoft.com> wrote in message > news:eWSkmSLPFHA.3024@TK2MSFTNGP10.phx.gbl... >> In the "Local" mode, the controls will take a RDL and datasets, and > process >> and render without the need of a report server. >> >> -- Robert >> This posting is provided "AS IS" with no warranties, and confers no > rights. >> >> >> "Bruce L-C [MVP]" <bruce_lcNOSPAM@hotmail.com> wrote in message >> news:%234isip4OFHA.3144@tk2msftngp13.phx.gbl... >> > Doesn't help you now but this is exactly the scenario that the new web > and >> > winform controls will help. The new controls will work either with or >> > without Report Server. So you could embed the control into your app and >> > provide it with the rdl to use. I believe you will also be able to give > it >> > the dataset to use as well. The next beta of Widbey will have these >> > controls >> > (which I believe should be out fairly soon). There will be a go live >> > license >> > with Widbey but not sure if that includes the use of these controls or >> > not. >> > Anyway, once the next beta is out you might want to investigate these >> > controls. >> > >> > >> > -- >> > Bruce Loehle-Conger >> > MVP SQL Server Reporting Services >> > >> > "vRam" <vRam@discussions.microsoft.com> wrote in message >> > news:E227049A-DBC5-4905-A4EA-BF939567046B@microsoft.com... >> >> We had a very similar scenario. We used webservice. crated our RDL > using >> > our >> >> custom application. Called Createreport method and loaded the rdl to >> > report >> >> server using a common user impersonation. This user has full authority > on >> >> report server. The report isrendered using the render method and the >> > binary >> >> data returned is saved as file to a our custom application folder > before >> >> delivered to user. >> >> >> >> I agree with you. It would have been nice if those DLL where >> >> programmable. >> >> >> >> "Damian Cugley" wrote: >> >> >> >> > We want to be able to render reports in our web application and >> >> > therefore have no need for the folders, roles, permissions system, >> >> > etc., >> >> > supplied by ReportServer: we already have a user database and >> >> > permissions system. It would be nice if we could load reports and >> >> > render them directly, rather than having to go via a web service, >> >> > especially as the web service has to be extended to understand our > user >> >> > database, and while writing the authentication extension is a >> >> > trivial >> >> > matter (since we already handle authentication), getting >> >> > ReportServer >> >> > to >> >> > either use the extension or otherwise explain what is wrong is > turning >> >> > out to be a nightmare exercise in frustration. >> >> > >> >> > For a stand-alone intranet-bound application where Windows domain >> >> > log-ins the ReportServer arrangement makes sense, but for >> >> > integration >> >> > in >> >> > to existing applications which do not use Windows authentication it >> >> > makes Reporting Services a risky proposition at best (risky in the >> >> > sense >> >> > that writing the security extension *might* take one day, or might > take >> >> > six weeks during which your programmers develop ulcers and quit in >> >> > disgust). >> >> > >> >> > Of course, the DLLs that do the rendering are just sitting there in > the >> >> > ReportServer directory -- but given that they are even less > documented >> >> > than the security-extension configuration (and liable to change in >> >> > future versions), I don't think I could serious recommend we try to > use >> >> > them. Pity. >> >> > >> >> > I don't suppose there are any plans to make the rendering class >> >> > libraries available to developers? >> >> > >> >> > >> >> > >> > >> > >> >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |