Ondersteunt SQL Server CLR Integration configuratiebestanden?

U moet een sqlservr.exe.config . plaatsen bestand in de \Binn map van de hoofdmap van die instantie. Bijvoorbeeld:

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

Als u SQL Server 2008 R2 (SP1) of nieuwer gebruikt, zou u de exacte locatie moeten kunnen vinden via de volgende query, die het volledige pad naar sqlservr.exe laat zien. :

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

In je code heb je deze regel bovenaan nodig:

using System.Configuration;

En dan zal dit werken:

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

Inhoud van de sqlservr.exe.config bestand:

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

Het is belangrijk op te merken dat, zoals vermeld in de link "Een toepassingsconfiguratie gebruiken...", wijzigingen in het configuratiebestand niet onmiddellijk beschikbaar zijn. Echter , jij niet opnieuw laden moet forceren door een van de in dat artikel genoemde methoden uit te voeren (d.w.z. DBCC FREESYSTEMCACHE , en het herstarten van SQL Server). Het enige dat nodig is om actuele informatie te krijgen, is om de specifieke sectie die u gebruikt opnieuw te laden via ConfigurationManager.RefreshSection(string sectionName) zoals weergegeven in het bovenstaande voorbeeld. Zie onderstaande opmerking over gebruik en prestaties.

Bronnen:

System.Configuration.dll gebruiken in .NET sprocs en UDF's
Een toepassingsconfiguratiebestand (app.config/web.config) gebruiken in SQL Server CLR-integratie

Ook moet u, tenzij het absoluut nodig is, uw assembly niet maken als UNSAFE . Als je alleen maar TCP-verbindingen met andere machines probeert te maken, zou dat alleen EXTERNAL_ACCESS moeten vereisen .

GEBRUIK EN PRESTATIES

Zoals gesuggereerd door Joe B in een opmerking hieronder, is er een kleine prestatiehit voor de RefreshSection operatie. Als de code die de vernieuwing bevat meer dan eens per paar minuten wordt aangeroepen, kan dit een merkbare impact hebben (een impact die onnodig is gezien het gebrek aan frequentie van het wijzigen van een configuratiebestand). In dit geval wilt u de aanroep naar RefreshSection . verwijderen van de code die vaak wordt aangeroepen en de verversing onafhankelijk afhandelt.

Een benadering zou zijn om een SQLCLR Stored Procedure of Scalar Function te hebben die alleen de refresh doet en niets anders. Dit kan worden uitgevoerd wanneer er een wijziging is aangebracht in het configuratiebestand.

Een andere benadering zou zijn om het app-domein te verwijderen, waardoor het configuratiebestand opnieuw wordt geladen wanneer er de volgende keer naar een SQLCLR-object in die database wordt verwezen. Een vrij eenvoudige methode om alle app-domeinen in een bepaalde database opnieuw te laden (maar niet voor de hele instantie) is door de TRUSTWORTHY om te draaien. instelling Aan en dan weer Uit, of Uit en dan weer Aan, afhankelijk van de huidige status van die instelling. De onderstaande code zal de huidige status van die instelling controleren en dienovereenkomstig omdraaien:

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;

Alsjeblieft gebruik geen van de meer drastische methoden -- DBCC FREESYSTEMCACHE , uitschakelen en vervolgens inschakelen van de clr enabled systeeminstelling, het opnieuw opstarten van de Instance, enz. -- omdat het bijna nooit nodig is om dit te doen. Vooral het herstarten van de Instance, of DBCC FREESYSTEMCACHE die alle drops laat vallen gegevens in de cache voor de hele Instance, die veel meer beïnvloedt dan alleen SQLCLR.

UPDATE BETREFFENDE SQL SERVER OP LINUX

SQL Server is nu, vanaf versie 2017, beschikbaar op Linux (woo hoo!). Het lijkt er echter op dat het lezen van het app-configuratiebestand niet werken op Linux. Ik heb veel combinaties geprobeerd van sqlservr.exe.[Cc]onfig en sqlservr.[Cc]onfig , etc, en dergelijke en hebben niets aan het werk gekregen. Het specificeren van een configuratiebestand kan niet werken omdat daarvoor EXTERNAL_ACCESS . nodig is toestemming en alleen SAFE Assemblies zijn toegestaan op Linux (vanaf nu tenminste). Als ik een manier vind om het werkend te krijgen, zal ik de details hier posten.