Friday, March 9, 2012

expression-based connection strings difficult to manage

Expression-based connection strings are great but they are specific to each report which makes them difficult to maintain. Shared expression-based connection strings are not supported.

I'm looking for a way around this. I'm hoping to write a custom data extension, and in the custom data extension, do all the "dynamic" logic that sets the connection string (which you normally would be doing in your expression-based connection string).

I know the above can be done. What I don't know is how, inside a custom data extension, to get the value of expressions like User!UserID? (I want the connection to run under stored credentials, but I want to customize the connection string and add a property to it based on the UserID who is logged into Report Manager.)

Create a assembly with a static method that takes a text parameter(userid) and returns the connectionstring and add that assembly (look in BOL for custom code or something like that on how to add it to a report and deploy the assembly to the report server) and then in the datasource it is something like this =Assembly.Class.Function(User!UserID).

I have done it myself, but in my case it was depending on the reportpath.|||

Interesting workaround, SteffoS. Thanks for the reply. That may be the best available. The only downside is that you have to actually use expression-based connection strings. And in doing that, there are two unfortunate problems:

1. Every report must call that expression instead of doing development as normal

2. (More importantly) you can't preview your dataset when it's tied to an expression-based connection string. The workaround to that is switching to a shared datasource during development, then making it an expression before you deploy, but that's a pain in the rear.

Anyone else have thoughts?

No comments:

Post a Comment