Поддържа ли интеграцията на SQL Server CLR конфигурационни файлове?

Трябва да поставите sqlservr.exe.config файл в \Binn папка на основната папка на този екземпляр. Например:

C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn

Ако използвате SQL Server 2008 R2 (SP1) или по-нова версия, трябва да можете да намерите точното местоположение чрез следната заявка, която показва пълния път до sqlservr.exe :

SELECT [filename] FROM sys.dm_server_services WHERE servicename LIKE N'SQL Server (%';

Във вашия код ви е необходим този ред в горната част:

using System.Configuration;

И тогава това ще работи:

[SqlFunction(DataAccess = DataAccessKind.None, IsDeterministic = true)]
public static SqlString GetConfig(SqlString WhichOne)
{
    ConfigurationManager.RefreshSection("connectionStrings");
    return ConfigurationManager.ConnectionStrings[WhichOne.Value].ToString();
}

Съдържание на sqlservr.exe.config файл:

<?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>

Важно е да се отбележи, че както е посочено в връзката „Използване на конфигурация на приложение...“, промените, направени в конфигурационния файл, не са достъпни веднага. ОБАЧЕ , вие не трябва да принудите презареждане, като направите един от методите, споменати в тази статия (т.е. DBCC FREESYSTEMCACHE и рестартиране на SQL Server). Всичко, което е необходимо, за да получите текуща информация, е да презаредите конкретната секция, която използвате, чрез ConfigurationManager.RefreshSection(string sectionName), както е показано в примера по-горе. Моля, вижте бележката по-долу относно употребата и производителността.

Ресурси:

• Използване на System.Configuration.dll в .NET sprocs и UDFs
• Използване на файл с конфигурация на приложение (app.config/web.config) в SQL Server CLR интеграция

Освен това, освен ако не е абсолютно необходимо, не трябва да създавате своя сбор като UNSAFE . Ако просто се опитвате да направите TCP връзки с други машини, това трябва да изисква само EXTERNAL_ACCESS .

ИЗПОЛЗВАНЕ И ИЗПЪЛНЕНИЕ

Както беше предложено от Joe B в коментар по-долу, има лек удар в производителността за RefreshSection операция. Ако кодът, съдържащ опресняването, ще бъде извикан повече от веднъж на всеки няколко минути, тогава това може да има забележимо въздействие (въздействие, което е ненужно предвид липсата на честота на промяна на конфигурационния файл). В този случай ще искате да премахнете извикването към RefreshSection от кода, който се извиква често и обработват опресняването независимо.

Един подход би бил да имате SQLCLR Съхранена процедура или скаларна функция, която просто прави опресняване и нищо друго. Това може да се изпълни всеки път, когато е направена промяна в конфигурационния файл.

Друг подход би бил да се разтовари App Domain, който ще презареди конфигурационния файл при следващото препращане към всеки SQLCLR обект в тази база данни. Един доста прост метод за презареждане на всички домейни на приложения в конкретна база данни (но не в целия екземпляр) е да обърнете TRUSTWORTHY настройка Вкл. и след това отново Изкл. или Изкл. и след това отново Вкл., в зависимост от текущото състояние на тази настройка. Кодът по-долу ще провери текущото състояние на тази настройка и ще я обърне съответно:

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;

Моля не използвайте някой от по-драстичните методи -- DBCC FREESYSTEMCACHE , деактивиране и след това активиране на clr enabled настройка на системата, рестартиране на екземпляра и т.н. - тъй като почти никога не е необходимо да го правите. Особено рестартиране на екземпляра или DBCC FREESYSTEMCACHE което пуска всички кеширани данни за целия екземпляр, което засяга много повече от SQLCLR.

АКТУАЛИЗИРАНЕ ОТНОСНО SQL СЪРВЪР НА LINUX

SQL Server вече е наличен, като се започне с версия 2017, на Linux (уу!). Изглежда обаче, че четенето от конфигурационния файл на приложението не работа на Linux. Опитах много комбинации от sqlservr.exe.[Cc]onfig и sqlservr.[Cc]onfig и т.н. и други подобни и не са получили нищо да работи. Посочването на конфигурационен файл не може да работи, тъй като това изисква EXTERNAL_ACCESS разрешение и само SAFE Асембирането е разрешено в Linux (поне към момента). Ако намеря начин да го накарам да работи, ще публикувам подробностите тук.