Vous devez placer un sqlservr.exe.config fichier dans le \Binn dossier du dossier racine de cette instance. Par exemple :
C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn
Si vous utilisez SQL Server 2008 R2 (SP1) ou une version plus récente, vous devriez pouvoir trouver l'emplacement exact via la requête suivante, qui affiche le chemin complet vers sqlservr.exe :
SELECT [filename] FROM sys.dm_server_services WHERE servicename LIKE N'SQL Server (%';
Dans votre code, vous avez besoin de cette ligne en haut :
using System.Configuration;
Et alors cela fonctionnera :
[SqlFunction(DataAccess = DataAccessKind.None, IsDeterministic = true)]
public static SqlString GetConfig(SqlString WhichOne)
{
ConfigurationManager.RefreshSection("connectionStrings");
return ConfigurationManager.ConnectionStrings[WhichOne.Value].ToString();
}
Contenu de sqlservr.exe.config fichier :
<?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>
Il est important de noter que, comme indiqué dans le lien "Utilisation d'une configuration d'application...", les modifications apportées au fichier de configuration ne sont pas immédiatement disponibles. CEPENDANT , vous ne faites pas besoin de forcer un rechargement en appliquant l'une des méthodes mentionnées dans cet article (c'est-à-dire DBCC FREESYSTEMCACHE , et redémarrage de SQL Server). Tout ce qui est nécessaire pour obtenir les informations actuelles est de recharger la section particulière que vous utilisez via ConfigurationManager.RefreshSection(string sectionName) comme indiqué dans l'exemple ci-dessus. Veuillez consulter la note ci-dessous concernant l'utilisation et les performances.
Ressources :
- Utilisation de System.Configuration.dll dans les sprocs .NET et les UDF
- Utilisation d'un fichier de configuration d'application (app.config/web.config) dans l'intégration SQL Server CLR
De plus, à moins que vous n'en ayez absolument besoin, vous ne devez pas créer votre assembly en tant que UNSAFE . Si vous essayez simplement d'établir des connexions TCP avec d'autres machines, cela ne devrait nécessiter que EXTERNAL_ACCESS .
UTILISATION ET PERFORMANCE
Comme suggéré par Joe B dans un commentaire ci-dessous, il y a une légère baisse de performance pour la RefreshSection opération. Si le code contenant l'actualisation va être appelé plus d'une fois toutes les deux minutes, cela peut avoir un impact notable (un impact qui n'est pas nécessaire étant donné le manque de fréquence de modification d'un fichier de configuration). Dans ce cas, vous voudrez supprimer l'appel à RefreshSection à partir du code fréquemment appelé et gérer l'actualisation indépendamment.
Une approche serait d'avoir une procédure stockée SQLCLR ou une fonction scalaire qui ne fait que l'actualisation et rien d'autre. Cela peut être exécuté chaque fois qu'une modification est apportée au fichier de configuration.
Une autre approche consisterait à décharger le domaine d'application qui rechargera le fichier de configuration la prochaine fois qu'un objet SQLCLR de cette base de données sera référencé. Une méthode assez simple pour recharger tous les domaines d'application dans une base de données particulière (mais pas sur l'ensemble de l'instance) consiste à inverser le TRUSTWORTHY Activé puis Désactivé à nouveau, ou Désactivé puis Activé à nouveau, selon l'état actuel de ce paramètre. Le code ci-dessous vérifiera l'état actuel de ce paramètre et l'inversera en conséquence :
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;
S'il vous plaît n'utilisez aucune des méthodes les plus drastiques -- DBCC FREESYSTEMCACHE , en désactivant puis en activant le clr enabled configuration du système, redémarrage de l'instance, etc., car il n'est presque jamais nécessaire de le faire. Notamment en redémarrant l'Instance, ou DBCC FREESYSTEMCACHE qui laisse tomber tout données mises en cache pour l'intégralité de l'instance, ce qui affecte bien plus que SQLCLR.
MISE À JOUR CONCERNANT SQL SERVER SUR LINUX
SQL Server est maintenant, à partir de la version 2017, disponible sur Linux (woo hoo !). Cependant, il semble que la lecture à partir du fichier de configuration de l'application ne le fasse pas travailler sous Linux. J'ai essayé de nombreuses combinaisons de sqlservr.exe.[Cc]onfig et sqlservr.[Cc]onfig , etc., et autres et n'ont rien obtenu pour fonctionner. La spécification d'un fichier de configuration ne peut pas fonctionner car cela nécessite EXTERNAL_ACCESS permission et uniquement SAFE Les assemblages sont autorisés sur Linux (pour le moment, du moins). Si je trouve un moyen de le faire fonctionner, je publierai les détails ici.
