SQL Anywhere stellt Unterstützung für gespeicherte CLR-Prozeduren und -Funktionen bereit. Eine gespeicherte CLR-Prozedur oder -Funktion verhält sich wie eine gespeicherte SQL-Prozedur oder -Funktion, abgesehen davon, dass der Code für die Prozedur oder Funktion in einer .NET-Sprache wie C# oder Visual Basic geschrieben ist und die Ausführung der Prozedur oder Funktion außerhalb des Datenbankservers stattfindet (d.h. innerhalb eines separaten .NET-Programms). Es gibt nur eine Instanz dieses .NET-Programms pro Datenbank. Alle Verbindungen, die CLR-Funktionen und gespeicherte Prozeduren ausführen, verwenden dieselbe .NET-Programminstanz, aber die Namensbereiche für die einzelnen Verbindungen sind getrennt. Statistiken werden für die Dauer der Verbindung aufrechterhalten, können aber nicht über Verbindungen hinweg gemeinsam genutzt werden. Es wird nur .NET Version 2.0 unterstützt.

Um eine externe CLR-Funktion oder -Prozedur aufzurufen, definieren Sie eine entsprechende gespeicherte Prozedur oder Funktion mit einer EXTERNAL NAME-Zeichenfolge, die festlegt, welche DLL geladen und welche Funktion innerhalb der Assembly aufgerufen werden soll. Sie müssen auch LANGUAGE CLR angeben, wenn Sie die gespeicherte Prozedur oder Funktion definieren. Hier ist eine Beispieldeklaration:

CREATE PROCEDURE clr_stored_proc( 
    IN p1 INT, 
    IN p2 UNSIGNED SMALLINT, 
    OUT p3 LONG VARCHAR) 
EXTERNAL NAME 'MyCLRTest.dll::MyCLRTest.Run( int, ushort, out string )' 
LANGUAGE CLR;

In diesem Beispiel ruft die gespeicherte Prozedur bei der Ausführung clr_stored_proc auf, lädt die DLL MyCLRTest.dll und ruft die Funktion MyCLRTest.Run auf. Die Prozedur clr_stored_proc übernimmt drei SQL-Parameter: zwei IN-Parameter, einen vom Typ INT und einen vom Typ UNSIGNED SMALLINT, und einen OUT-Parameter des Typs LONG VARCHAR. Auf der .NET-Seite werden diese drei Parameter in Eingabeargumente des Typs "int" und "ushort" sowie in ein Ausgabeargument des Typs "string" konvertiert. Zusätzlich zu out-Argumenten kann die CLR-Funktion auch ref-Argumente haben. Ein Benutzer muss ein Argument "ref CLR" deklarieren, wenn die entsprechende gespeicherte Prozedur einen INOUT-Parameter hat.

Die folgende Tabelle enthält die verschiedenen CLR-Argumenttypen und den entsprechenden empfohlenen SQL-Datentyp:

Die Deklaration der DLL kann ein relativer oder absoluter Pfad sein. Wird ein relativer Pfad angegeben, durchsucht das externe .NET-Programm den Pfad und andere Positionen nach der DLL. Das Programm durchsucht nicht den Global Assembly Cache (GAC) nach der DLL.

Wie die bestehenden gespeicherten Java-Prozeduren und Funktionen können gespeicherte CLR-Prozeduren und -Funktionen serverseitige Anforderungen an die Datenbank und Ergebnismengen zurückgeben. Auch werden wie bei Java alle an Console.Out und Console.Error übermittelten Informationen automatisch an das Fenster "Datenbankservermeldungen" weitergeleitet.

Weitere Hinweise zur Durchführung von serverseitigen Anforderungen und zur Rückgabe von Ergebnismengen einer CLR-Funktion oder gespeicherten Prozedur finden Sie in den Beispielen unter Beispielverzeichnis\SQLAnywhere\ExternalEnvironments\CLR.

Um CLR in der Datenbank zu verwenden, vergewissern Sie sich, dass der Datenbankserver in der Lage ist, die Position des CLR-Programms zu ermitteln und es zu starten. Sie können überprüfen, ob der Datenbankserver in der Lage ist, die Position des CLR-Programms zu ermitteln und es zu starten, indem Sie die folgende Anweisung ausführen:

START EXTERNAL ENVIRONMENT CLR;

Wenn der Datenbankserver CLR nicht starten kann, findet er wahrscheinlich die CLR-Programmdatei nicht. Die CLR-Programmdatei ist dbextclr12.exe. Vergewissern Sie sich, dass sich diese Datei im Ordner Installationsverzeichnis\Bin32 oder Installationsverzeichnis\Bin64 befindet, abhängig von der verwendeten Datenbankserver-Version.

Beachten Sie, dass die Anweisung START EXTERNAL ENVIRONMENT CLR nur benötigt wird, um zu überprüfen, ob der Datenbankserver in der Lage ist, CLR zu starten. Üblicherweise startet CLR automatisch, wenn Sie einen Aufruf einer gespeicherten CLR-Prozedur oder Funktion durchführen.

Die Anweisung STOP EXTERNAL ENVIRONMENT CLR ist auch nicht erforderlich, um eine Instanz von CRL zu stoppen, weil die Instanz mit dem Ende der Verbindung automatisch beendet wird. Wenn Sie allerdings die Arbeit mit CLR abgeschlossen haben und Ressourcen freigeben wollen, entfernt die Anweisung STOP EXTERNAL ENVIRONMENT CLR die CLR-Instanz für Ihre Verbindung.

Im Gegensatz zu den externen Perl-, PHP- und Java-Umgebungen muss bei der CLR-Umgebung kein Objekt in der Datenbank installiert werden. Daher müssen Sie keine INSTALL-Anweisungen ausführen, bevor Sie die externe CLR-Umgebung verwenden.

Hier ist ein Beispiel einer in C# geschriebenen Funktion, die in einer externen Umgebung ausgeführt werden kann.

public class StaticTest
{
    private static int val = 0;

    public static int GetValue() {
        val += 1;
        return val;
    }
}

Wenn sie in eine dynamische Verknüpfungsbibliothek kompiliert wird, kann diese Funktion von einer externen Umgebung aufgerufen werden. Ein ausführbares Image namens dbextclr12.exe wird vom Datenbankserver gestartet und lädt die dynamische Verknüpfungsbibliothek. In SQL Anywhere stehen verschiedene Versionen dieses Programms zur Verfügung. Unter Windows beispielsweise gibt es sowohl 32-Bit-Programme als auch 64-Bit-Programme. Die eine Version ist für die Verwendung mit der 32-Bit-Version und die andere für die Verwendung mit der 64-Bit-Version des Datenbankservers bestimmt.

Um diese Anwendung in eine dynamische Verknüpfungsbibliothek unter Verwendung des C#-Compilers von Microsoft zu kompilieren, verwenden Sie einen ähnlichen Befehl wie den folgenden: Hierbei wird angenommen, dass sich der Quellcode für das obenstehende Beispiel in einer Datei namens StaticTest.cs befindet.

csc /target:library /out:clrtest.dll StaticTest.cs

Dieser Befehl platziert den kompilierten Code in eine DLL namens clrtest.dll. Um die kompilierte C#-Funktion aufzurufen, wird ein Wrapper unter Verwendung von Interactive SQL folgendermaßen festgelegt:

CREATE FUNCTION stc_get_value() 
RETURNS INT 
EXTERNAL NAME 'clrtest.dll::StaticTest.GetValue() int' 
LANGUAGE CLR;

Bei CLR wird die Zeichenfolge EXTERNAL NAME in einer einzigen Zeile mit SQL-Code angegeben. Möglicherweise müssen Sie den Pfad zur DLL als Teil der Zeichenfolge EXTERNAL NAME aufnehmen, damit die DLL gefunden wird. Im Fall von abhängigen Assemblies (z.B. wenn myLib.dll Code enthält, der Funktionen in myOtherLib.dll abruft oder auf andere Weise von ihr abhängt) liegt es am .NET-Framework, die Abhängigkeiten aufzulösen. Die externe CLR-Umgebung führt das Laden der angegebenen Assembly durch, aber möglicherweise sind zusätzliche Schritte erforderlich, um zu gewährleisten, dass abhängige Assemblies geladen werden. Eine Möglichkeit besteht darin, alle Abhängigkeiten im globalen Assembly-Cache (GAC) zu registrieren, indem Sie das gacutil-Dienstprogramm von Microsoft verwenden, das mit dem .NET-Framework installiert wird. In Fall von benutzerdefinierten Bibliotheken erfordert gacutil, dass diese mit einem starken Namensschlüssel signiert werden, bevor sie im GAC registriert werden können.

Für die kompilierte C#-Beispielfunktion führen Sie die folgende Anweisung aus.

SELECT stc_get_value();

Bei jedem Aufruf der C#-Funktion wird ein neues Ganzzahl-Ergebnis erzeugt. Die Sequenz der zurückgegebenen Werte ist 1, 2, 3 usw.

Weitere Hinweise und Beispiele zur Unterstützung für CLR in der Datenbank finden Sie unter den Beispielen, die sich im Verzeichnis Beispielverzeichnis\SQLAnywhere\ExternalEnvironments\CLR befinden.