Czy integracja SQL Server CLR obsługuje pliki konfiguracyjne?

Musisz umieścić sqlservr.exe.config plik w \Binn folderu głównego folderu tej instancji. Na przykład:

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

Jeśli używasz SQL Server 2008 R2 (SP1) lub nowszego, powinieneś być w stanie znaleźć dokładną lokalizację za pomocą następującego zapytania, które pokazuje pełną ścieżkę do sqlservr.exe :

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

W swoim kodzie potrzebujesz tego wiersza na górze:

using System.Configuration;

A wtedy to zadziała:

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

Zawartość sqlservr.exe.config plik:

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

Należy zauważyć, że, jak stwierdzono w łączu „Używanie konfiguracji aplikacji...”, zmiany wprowadzone w pliku konfiguracyjnym nie są natychmiast dostępne. JEDNAK , nie trzeba wymusić przeładowanie, wykonując jedną z metod wymienionych w tym artykule (tj. DBCC FREESYSTEMCACHE i ponowne uruchomienie programu SQL Server). Aby uzyskać aktualne informacje, wystarczy ponownie załadować konkretną sekcję, której używasz, za pośrednictwem ConfigurationManager.RefreshSection(string sectionName), jak pokazano w powyższym przykładzie. Zapoznaj się z poniższą uwagą dotyczącą użytkowania i wydajności.

Zasoby:

• Korzystanie z System.Configuration.dll w .NET sprocs i UDF
• Korzystanie z pliku konfiguracji aplikacji (app.config/web.config) w integracji z SQL Server CLR

Ponadto, o ile nie jest to absolutnie konieczne, nie powinieneś tworzyć swojego zespołu jako UNSAFE . Jeśli próbujesz tylko nawiązać połączenia TCP z innymi maszynami, powinno to wymagać tylko EXTERNAL_ACCESS .

UŻYCIE I WYDAJNOŚĆ

Jak sugeruje Joe B w komentarzu poniżej, istnieje niewielki spadek wydajności dla RefreshSection operacja. Jeśli kod zawierający odświeżanie będzie wywoływany więcej niż raz na kilka minut, może to mieć zauważalny wpływ (wpływ, który jest niepotrzebny, biorąc pod uwagę brak częstotliwości zmian pliku konfiguracyjnego). W takim przypadku będziesz chciał usunąć wywołanie RefreshSection z kodu, który jest często wywoływany i niezależnie obsłuż odświeżanie.

Jednym z podejść byłoby posiadanie procedury składowanej SQLCLR lub funkcji skalarnej, która po prostu wykonuje odświeżanie i nic więcej. Może to zostać wykonane za każdym razem, gdy dokonana została zmiana w pliku konfiguracyjnym.

Innym podejściem byłoby zwolnienie domeny aplikacji, która ponownie załaduje plik konfiguracyjny przy następnym odwołaniu do dowolnego obiektu SQLCLR w tej bazie danych. Jedną z dość prostych metod ponownego załadowania wszystkich domen aplikacji w określonej bazie danych (ale nie w całej instancji) jest odwrócenie TRUSTWORTHY ustawienie Włącz i ponownie Wyłącz lub Wyłącz i ponownie Włącz, w zależności od aktualnego stanu tego ustawienia. Poniższy kod sprawdzi aktualny stan tego ustawienia i odpowiednio go odwróci:

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;

Proszę nie używaj żadnej z bardziej drastycznych metod -- DBCC FREESYSTEMCACHE , wyłączając, a następnie włączając clr enabled ustawienia systemu, ponowne uruchomienie instancji itp. — ponieważ prawie nigdy nie jest to konieczne. Zwłaszcza ponowne uruchomienie instancji lub DBCC FREESYSTEMCACHE który upuszcza wszystkie buforowane dane dla całej instancji, co ma wpływ na znacznie więcej niż tylko SQLCLR.

AKTUALIZACJA DOTYCZĄCA SERWERA SQL W LINUX

SQL Server jest teraz, począwszy od wersji 2017, dostępny w systemie Linux (woo hoo!). Wygląda jednak na to, że odczyt z pliku konfiguracyjnego aplikacji nie pracować na Linuksie. Próbowałem wielu kombinacji sqlservr.exe.[Cc]onfig i sqlservr.[Cc]onfig itp. i tym podobne i nic nie działało. Określenie pliku konfiguracyjnego nie może działać, ponieważ wymaga EXTERNAL_ACCESS uprawnienia i tylko SAFE Zespoły są dozwolone w systemie Linux (przynajmniej w tej chwili). Jeśli znajdę sposób, aby to działało, opublikuję szczegóły tutaj.