Hello everyone,
I have a question regarding named connection strings. I'm sure this question or something similar has been asked, but I'm not finding a clear answer or a best approach documented. There is so much posted out there...it's a lot to wade through. For the record, I'm using Telerik Report Q2 2013.
Here's my situation. I'm creating reports for web projects in separate solutions. Inside a web.config file for a particular web project, I have a connection string named say "MyDBContext".
In my report solution where I create my reports for this particular project. Let's call it MyReports. I use the report wizard, I "Add New Data Source", choose "SQL Data Source", give it name or accept the default one, specify the connection string (using SqlClient Data Provider), and I do "Save this connection string with a name that I hope to be used when this report is executed in my web project. In this example "MyDBContext" to match the named connection in my web project.
What I see is that the SqlDataSource in that report actually has the full data source specified in the ConnectionString property rather than just a reference to the connection string that was added to my app.config file. I can change the connection string to reference the named connection string; however, instead of it being just "MyDBContext", which would work in my WebProject, it is called "MyReports.Properties.Settings.MyDBContext", which of course, will not match the connection string in my web project and so I won't be able to make a successful connection when using the report DLL there as is. What I am doing is renaming the named connection in my app.config from "MyReports.Properties.Settings.MyDBContext" to just "MyDBContext" and then changing the ConnectionString property in my report's datasource to be just "MyDBContext"
Is this the right approach ? We are new to using the Telerik reporting product and I would like to start out with best practices. Unfortunately, there is so much information out there, it's difficult to determine what those best practices are.
Any thoughts or suggestion would be greatly appreciated.
Thank you -- Jeff Gaiche
I have a question regarding named connection strings. I'm sure this question or something similar has been asked, but I'm not finding a clear answer or a best approach documented. There is so much posted out there...it's a lot to wade through. For the record, I'm using Telerik Report Q2 2013.
Here's my situation. I'm creating reports for web projects in separate solutions. Inside a web.config file for a particular web project, I have a connection string named say "MyDBContext".
In my report solution where I create my reports for this particular project. Let's call it MyReports. I use the report wizard, I "Add New Data Source", choose "SQL Data Source", give it name or accept the default one, specify the connection string (using SqlClient Data Provider), and I do "Save this connection string with a name that I hope to be used when this report is executed in my web project. In this example "MyDBContext" to match the named connection in my web project.
What I see is that the SqlDataSource in that report actually has the full data source specified in the ConnectionString property rather than just a reference to the connection string that was added to my app.config file. I can change the connection string to reference the named connection string; however, instead of it being just "MyDBContext", which would work in my WebProject, it is called "MyReports.Properties.Settings.MyDBContext", which of course, will not match the connection string in my web project and so I won't be able to make a successful connection when using the report DLL there as is. What I am doing is renaming the named connection in my app.config from "MyReports.Properties.Settings.MyDBContext" to just "MyDBContext" and then changing the ConnectionString property in my report's datasource to be just "MyDBContext"
Is this the right approach ? We are new to using the Telerik reporting product and I would like to start out with best practices. Unfortunately, there is so much information out there, it's difficult to determine what those best practices are.
Any thoughts or suggestion would be greatly appreciated.
Thank you -- Jeff Gaiche