0

In the properties of a data source in SSRS, I can specify a Windows domain account to use, like this:

SSRS data source properties

This data source was originally deployed from a SSDT project and I need these settings to be reflected in that project - otherwise the data source will no longer work correctly the next time that the project is deployed.

Unfortunately SSDT does not seem to provide a way of doing this. If I specify credentials here it automatically assumes SQL Server authentication (which is of no use to me).

SSDT data source properties

Am I missing something, or am I once again the victim of Microsoft's inability to be consistent?

Improve this question
2
  • have you tried using the domain account in the 'use this user name and password' option? as far as I'm aware SSDT doesn't care which it is
    – Ste Bov
    Commented Oct 16, 2015 at 11:45
  • I have. It failed to authenticate with the error "Attempting to use an NT account name with SQL Server Authentication".
    – paulH
    Commented Oct 16, 2015 at 12:20

1 Answer 1

Reset to default
1

There is no option to set a data source within the client tool to use a different Windows account. This is by design and is consistent with how Microsoft designed most all client tools (e.g. works the same way in BIDS, SSMS, etc.).

Your only option I know of would be to simply not redeploy the shared data source.

Improve this answer
5
  • That was what I feared. I disagree that it is "by design" however. It might work the same way for other client tools but SSDT is specifically designed for creating projects to push out to SSRS, and SSRS specifically allows this option. I would say this is more "by oversight" or "by carelessness" or "by lack of communication between the SSRS and SSDT teams".
    – paulH
    Commented Oct 16, 2015 at 12:25
  • SSRS server allows the option. I have no intention of EVER saving a production Windows account in a client project file...you would violate multiple security standards if that option was available. I believe that to be the sole reason it does not allow it because no one can justify to me why they need to save a production login in a developer's tool.
    – user507
    Commented Oct 16, 2015 at 12:54
  • I agree with everything that you say, except that in my case there exists a high likelihood that at some point in the future some developer will re-deploy this project in the entirely reasonable assumption that the project is an accurate reflection of what is on the production server, and then they will not understand why it has broken or how to fix it as the original data source will have been over-written.
    – paulH
    Commented Oct 16, 2015 at 13:53
  • I think, given the options, I need to re-think how I am setting this up.
    – paulH
    Commented Oct 16, 2015 at 13:54
  • I don't see that as a design issue of the client tool but of the developer/user understanding how it works and following a designed deployment process. The method of changing the data source for SSRS once deployed to the server has been in place from the beginning (or at least once the feature was added), you couldn't do it in BIDS either.
    – user507
    Commented Oct 16, 2015 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.