better managability for expression-based connection strings - by GregGalloway

Status : 

 


22
0
Sign in
to vote
ID 278658 Comments
Status Active Workarounds
Type Suggestion Repros 0
Opened 5/26/2007 7:40:38 PM
Access Restriction Public

Description

You should be able to administer expression based connection strings from Report Manager. You should be able to turn a hardcoded connection string into an expression based one. And you should be able to make a shared data source use an expression based connection string. And a shared data source which uses an expression-based connection string should be able to refer to report properties like User!UserID or report parameters or anything else. (The expression should not be validated during editing the shared data-source. If you get it wrong, it will blow up during report execution.)

As it currently is, you have to change the RDL when you deploy a report to the development server versus the production server (unless you use a custom assembly to control the connection string, which is a pain).

Also, when you develop a report with an expression-based connection string you lose functionality during report development (like the ability to preview your dataset). With the above suggestion, you could develop the report with a shared data source which is a hardcoded connection string (so you don't lose features during development). Then when you deploy to the server, you can switch it to be a shared data source which is an expression-based connection string.
Sign in to post a comment.
Posted by JaapJD on 11/16/2010 at 4:21 AM
We have a workaround to embed the datasource in the RDL and use a VS addin to prepare the RDL for deployment (and also the other way round if we want to have the preview functionality again in BIDS). But having this embedded datasource has another drawback: we are not able to do modifications in ReportBuilder, because ReportBuilder does not support custom data extensions. So we really need the possibility to have expression based connection strings in a shared datasource. And references to report parameters (of course not the query-based ones for which you need the datasource) should be resolved.
Posted by Microsoft on 7/20/2007 at 1:43 PM
Thank you for filing this issue - we will consider it for a future release.