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.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für