Question

I have a SQL Server 2017 database which contains some CLR stored procedures. When trying to call those CLR SP's, I get a "login failed" error back from the CLR SP.

My user is connected and works fine - it seems that the CLR SP is coded to run as another specific user.

I don't have access to the underlying code for the CLR SP's. Is there any way for me to change which user it's executing as?

Was it helpful?

Solution

Assuming that the SQLCLR method truly is trying to log into SQL Server as a non-existing login ("user" is database-level), then that should only be due to using a regular / external connection (instead of the internal "context connection") and specifying a SQL Server login and password (instead of using a trusted connection / integrated security). { still, having the exact error message is always helpful :-) }

In terms of keeping the same process, you have two main options:

  1. Re-compile the code with a new login and/or password:
    1. There is a slight chance that the source code is in sys.assembly_files (it would be a row where file_id <> 1), but that practice was done (at least by default) in earlier versions of Visual Studio / SSDT and you don't really see it that much anymore.
    2. Assuming that the source code isn't in that system view, you would need to export the actual assembly (same view, but this time you do want WHERE [file_id] = 1) and then you can use a disassembler to get the source code.
  2. A much easier path should be to just re-add that deleted login. Is there a reason not to? If you aren't sure what password is being used, the two options noted above for getting the source code would also be how you find the password.
Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top