SSRS2008R2 Data Driven Subscription username/password?

Question

SSRS2008R2 Data Driven Subscription username/password?

Lowell

SSC Guru

Points: 323518
More actions
July 21, 2014 at 9:05 am

#291347

I inherited an SSRS server that was not using best practices; each report had it's own custom data source, and each report had a seperate custom data source for the subscriptions.I'm trying to clean up that mess, and use shared data sources everywhere.
I'm a little bit confused on a data driven subscription;
at the bottom of this way below screen, a username and a password are required, on a per subscription basis, and i'm confused as to why.
this article here: has the following quote:
http://www.databasejournal.com/features/mssql/data-driven-subscription-in-ssrs-2008-r2.html
On the fourth step of the wizard, you need to specify delivery extension settings for the delivery mode you chose on the second step. You can specify different values for report execution, which will either come from the database or be static values; for example in the case of file share more, you can specify path, file name, extension, write mode and user name/password (either to come from database or to specify the static value) to be used by report server to put the file at the specified location:
as I read that, i'm telling it the credentials of a user that has access to the disk/folders? and I'm storing it on a per-report basis? that just screams wrong to me, as my knee jerk reaction is it should not be required, or that it should be inherited from some account at the server level, and not on a per-report basis. credentials expire, unless I create a special user, and I don't want to do that. can I just put in a default N/A value and blast past it?
The existing set up was using a specific user, and that just feels wrong.
I've got a subscription,and i created a shared data source to point to a Subscribers table.
my suite of subscription tables current do not have columns for username / password on a per report basis.
can anyone point out if those credentials are even relevant? what does your typical set up contain? do you store credentials per-report like that?
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

doug.brown SSCertifiable Points: 5607 More actions · Answer 1

AFAIK you need to enter credentials on all data-driven subscriptions. They are entered on all our data-driven subscriptions - we have a special reporting user for the credentials.

Abs-225476 Hall of Fame Points: 3483 More actions · Answer 2

Hi,

The shared data source refers to the connection information for the report data source so when it runs it uses the connection information stored on the server.

For the file share subscription you have to specify the username and password used to connect to the file share location. This connection information is allowing the report server to save the reports to the file location, this is not the same as the data source connection information.

You could as "doug.brown" says use a special reporting user for this connection. My view would be to create a view for the dds file share and save the connection information in the view.

HTH

Lowell SSC Guru Points: 323518 More actions · Answer 3

Thanks guys for confirming , evne when it's not what i wanted to here.

Just as you suggested, I've got a specific domain user to use for this now, it just didn't feel rightto have the credentials entered on a per-report basis. Actually the same thing happens in Windows Tasks that run under a different user context, it's just the process.

Subscriptions was a new addition to my toolbox, and i was comparing it to SQL experiences a little too much, i think.

Lowell

--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!