Die Verwendung erweiterter gespeicherter Prozeduren oder SP_OA gespeicherter Prozeduren zum Laden von CLR in SQL Server wird nicht unterstützt.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 322884

Zusammenfassung

SQL Server 2005 und höheren Versionen hosten Common Language Runtime (CLR) und unterstützen Prozeduren, Funktionen, Trigger, Typen und Aggregate, die in CLR-Sprachen geschrieben sind. In diesen Versionen können Sie CLR nicht mithilfe von erweiterten gespeicherten Prozeduren oder sp_OA gespeicherten Prozeduren laden.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 322884

Weitere Informationen

Die .NET Framework-Assembly System.Runtime.InteropServices bietet eine stabile Umgebung zum Aufrufen von Assemblys aus nicht verwaltetem Code. Es gibt jedoch mehrere technische Uneinigkeiten zwischen den internen Implementierungen von CLR und SQL Server.

Threading

Zur Steigerung der Leistung implementiert die CLR den lokalen Threadspeicher.

Darüber hinaus verwendet CLR nur die threadbasierte Planung und unterstützt keine Fiber-Modus-Planung. SQL Server können jedoch die Planung im Fiber-Modus verwenden. Um diese Eigenschaft zu konfigurieren, führen Sie die sp_configure gespeicherte Prozedur mithilfe der Option lightweight pooling aus. Weitere Informationen zu diesem Thema finden Sie unter Serverkonfigurationsoption "Lightweight Pooling".

Arbeitsspeicher

Die Verwendung erweiterter gespeicherter Prozeduren und die OLE-Automatisierung werden beide im virtuellen Speicheradressraum des Arbeitsspeichers von SQL Server ausgeführt. Der Standard SQL Server Arbeitsspeicher ist nur ein Bruchteil des Arbeitsspeichers, den SQL Server potenziell verwenden können, und CLR konkurriert mit vorhandenen Implementierungen für diese Speicherressourcen.

COM-Interoperabilität

In diesem Abschnitt wird insbesondere die Verwendung der OLE-Automatisierung in SQL Server behandelt und gilt sowohl für IN-Process- als auch out-of-Process-COM-Objekte. Assemblymetadaten für Funktionsschnittstellen implementieren einen typisierten Mechanismus für alle Aufrufe.

Im Rahmen dieses Entwurfs muss der COM Callable-Wrapper für eine Assembly einen externen Mechanismus zum Zuordnen einer ClassID zu einem Member einer verwalteten Klasse verwenden. Aufgrund dieser expliziten Zuordnung gibt es aus nicht verwalteter Perspektive keine Möglichkeit, eine Stammliste der verfügbaren Schnittstellen zu erstellen.

Die erweiterte gespeicherte Prozedur sp_oaCreate verwendet die IUnknown::QueryInterface -Schnittstelle, um die Unterstützung des Objekts für eine bestimmte Schnittstelle zu bestimmen. Die Interoperabilität zwischen CLR und nicht verwaltetem Code basiert auf der IDispatch-Schnittstelle zum Implementieren von Schnittstellen. Da es keine Entsprechung zu einer QueryInterface Methode in einer CLR-basierten Assembly gibt, können Sie keine instance des Objekts erstellen.