Devi inserire un sqlservr.exe.config file nel \Binn cartella della cartella principale di quell'istanza. Ad esempio:
C:\Programmi\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn
Se utilizzi SQL Server 2008 R2 (SP1) o versioni successive, dovresti riuscire a trovare la posizione esatta tramite la query seguente, che mostra il percorso completo di sqlservr.exe :
SELECT [filename] FROM sys.dm_server_services WHERE servicename LIKE N'SQL Server (%';
Nel tuo codice, hai bisogno di questa riga in alto:
using System.Configuration;
E poi questo funzionerà:
[SqlFunction(DataAccess = DataAccessKind.None, IsDeterministic = true)]
public static SqlString GetConfig(SqlString WhichOne)
{
ConfigurationManager.RefreshSection("connectionStrings");
return ConfigurationManager.ConnectionStrings[WhichOne.Value].ToString();
}
Contenuto di sqlservr.exe.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="Stuff" connectionString="Trusted_Connection=true; Enlist=false;" />
<add name="ClrTest" connectionString="boo hoo" />
</connectionStrings>
</configuration>
È importante notare che, come indicato nel collegamento "Utilizzo di una configurazione dell'applicazione...", le modifiche apportate al file di configurazione non sono immediatamente disponibili. COMUNQUE , tu non è necessario forzare un ricaricamento eseguendo uno dei metodi menzionati in quell'articolo (ad esempio DBCC FREESYSTEMCACHE e riavviando SQL Server). Tutto ciò che è necessario per ottenere le informazioni correnti è ricaricare la sezione particolare che stai usando tramite ConfigurationManager.RefreshSection(string sectionName) come mostrato nell'esempio precedente. Consulta la nota di seguito relativa all'utilizzo e alle prestazioni.
Risorse:
- Utilizzo di System.Configuration.dll in sprocs e UDF .NET
- Utilizzo di un file di configurazione dell'applicazione (app.config/web.config) nell'integrazione CLR di SQL Server
Inoltre, a meno che non sia assolutamente necessario, non dovresti creare il tuo assembly come UNSAFE . Se stai solo cercando di stabilire connessioni TCP con altre macchine, ciò dovrebbe richiedere solo EXTERNAL_ACCESS .
UTILIZZO E PRESTAZIONI
Come suggerito da Joe B in un commento qui sotto, c'è un leggero calo delle prestazioni per la RefreshSection operazione. Se il codice contenente l'aggiornamento verrà chiamato più di una volta ogni due minuti, può avere un impatto notevole (un impatto non necessario data la mancanza di frequenza di modifica di un file di configurazione). In questo caso, dovrai rimuovere la chiamata a RefreshSection dal codice che viene chiamato frequentemente e gestisce l'aggiornamento in modo indipendente.
Un approccio sarebbe quello di avere una stored procedure SQLCLR o una funzione scalare che esegue solo l'aggiornamento e nient'altro. Questo può essere eseguito ogni volta che viene apportata una modifica al file di configurazione.
Un altro approccio sarebbe scaricare l'App Domain che ricaricherà il file di configurazione la prossima volta che verrà fatto riferimento a qualsiasi oggetto SQLCLR in quel database. Un metodo abbastanza semplice per ricaricare tutti i domini app in un particolare database (ma non nell'intera istanza) è capovolgere il TRUSTWORTHY impostando On e quindi nuovamente Off, oppure Off e quindi nuovamente On, a seconda dello stato corrente di tale impostazione. Il codice seguente controllerà lo stato corrente di tale impostazione e lo capovolgerà di conseguenza:
IF (EXISTS(
SELECT sd.*
FROM sys.databases sd
WHERE sd.[name] = DB_NAME() -- or N'name'
AND sd.[is_trustworthy_on] = 0
))
BEGIN
PRINT 'Enabling then disabling TRUSTWORTHY...';
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
END;
ELSE
BEGIN
PRINT 'Disabling then enabling TRUSTWORTHY...';
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
END;
Per favore non utilizzare nessuno dei metodi più drastici -- DBCC FREESYSTEMCACHE , disabilitando quindi abilitando il clr enabled impostazione del sistema, riavvio dell'istanza e così via, poiché non è quasi mai necessario farlo. Soprattutto riavviando l'istanza o DBCC FREESYSTEMCACHE che elimina tutti dati memorizzati nella cache per l'intera istanza, che interessa molto di più del semplice SQLCLR.
AGGIORNAMENTO RELATIVO A SQL SERVER SU LINUX
SQL Server è ora, a partire dalla versione 2017, disponibile su Linux (woo hoo!). Tuttavia, sembra che la lettura dal file di configurazione dell'app non lavorare su Linux. Ho provato molte combinazioni di sqlservr.exe.[Cc]onfig e sqlservr.[Cc]onfig , ecc, e simili e non hanno ottenuto nulla per funzionare. La specifica di un file di configurazione non può funzionare in quanto richiede EXTERNAL_ACCESS permesso e solo SAFE Gli assembly sono consentiti su Linux (almeno per ora). Se trovo un modo per farlo funzionare, posterò i dettagli qui.
