views:

521

answers:

2

I'm writing a SQL CLR assembly that will be deployed to a third-party database server, but which needs to execute stored procedures residing in my database server. All the pieces are in place, but I don't know how to make the connection string configurable. Articles such as this: http://msdn.microsoft.com/en-us/library/ms345135%28SQL.90%29.aspx repeatedly assert that connection strings should not be hardcoded in production (obviously), but give no suggestions for how to make the connection string configurable.

Is there any way to deploy a settings file or otherwise provide configuration settings to a SQL CLR 2005 assembly?

A: 

Here is an article on Using an Application Configuration (app.config/web.config) File in SQL Server CLR Integration

I'm not sure how well it would work on a third party Sql Server instance though.

Gratzy
That's a really clever trick, but unfortunately, I can't use it on the production server.
warrenm
Can you table up your configurations then in a config table?
Gratzy
I really hate having to do this to pass config settings - we've had this situation both in SQL Server and in Biztalk - editing the .config file for the hosting application. If you have more than one or two components that do this, it can get REALLY ugly in that file, so I'd caution against this for maintainability alone. There's nothing wrong with it - it's the officially supported method - but I'm just not a fan of keeping all those settings there.
rwmnau
@rwmnau actually I don't even think a config file for SQL CLR is officially supported
Gratzy
A: 

I'd recommend either a configuration table (also suggested by Gratzy) or adding them to the registry and looking them up there (assuming your running your SQL Server as a proxy domain user, their HKCU is the safest place).

The registry would be my choice since it doesn't involve any schema changes to your database, and is less likely to be accidentally/purposefully edited by the client once it's deployed.

rwmnau
Storing connection strings in the registry seems like the most maintainable suggestion. Fortunately, read access to HKCU is included in the permission set for SQL CLR assemblies with "External Access" permissions (also required for creating remote SQL client connections). Thanks for the help!
warrenm