L’utilisation de procédures stockées étendues ou de procédures stockées SP_OA pour charger le CLR dans SQL Server n’est pas prise en charge
Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 322884
Résumé
SQL Server 2005 et versions ultérieures hébergent le Common Language Runtime (CLR) et prennent en charge les procédures, fonctions, déclencheurs, types et agrégats écrits dans des langages CLR. Dans ces versions, vous ne pouvez pas charger le CLR à l’aide de procédures stockées étendues ou sp_OA
de procédures stockées.
Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 322884
Plus d’informations
L’assembly System.Runtime.InteropServices
.NET Framework fournit un environnement robuste pour appeler des assemblys à partir de code non managé. Toutefois, il existe plusieurs discordances techniques entre les implémentations internes du CLR et SQL Server.
Filetage
Pour améliorer les performances, le CLR implémente le stockage local des threads.
En outre, le CLR utilise uniquement la planification basée sur des threads et ne prend pas en charge la planification en mode Fibre. Toutefois, SQL Server pouvez utiliser la planification en mode Fibre. Pour configurer cette propriété, exécutez la procédure stockée à l’aide sp_configure
de l’option de regroupement léger. Pour plus d’informations sur cette rubrique, consultez Option de configuration de serveur de regroupement léger.
Mémoire
L’utilisation de procédures stockées étendues et d’OLE Automation s’exécutent dans l’espace d’adressage de mémoire virtuelle de la mémoire de SQL Server. La mémoire SQL Server par défaut n’est qu’une fraction de la mémoire que SQL Server pouvez utiliser et le CLR est en concurrence avec toutes les implémentations existantes pour ces ressources de mémoire.
Interopérabilité COM
Cette section traite spécifiquement de l’utilisation d’OLE Automation dans SQL Server et s’applique aux objets COM in-process et out-of-process. Les métadonnées d’assembly pour les interfaces de fonction implémentent un mécanisme typé pour tous les appels.
Dans le cadre de cette conception, le wrapper COM Callable pour un assembly doit utiliser un mécanisme externe de mappage d’un ClassID à un membre d’une classe managée. En raison de ce mappage explicite, il n’est pas possible, d’un point de vue non managé, d’établir une liste racine des interfaces disponibles.
La procédure sp_oaCreate
stockée étendue utilise l’interface IUnknown::QueryInterface
pour déterminer la prise en charge de l’objet pour une interface particulière. L’interopérabilité entre le CLR et le code non managé s’appuie sur l’interface IDispatch pour implémenter des interfaces. Étant donné qu’il n’existe pas d’équivalent à une QueryInterface
méthode dans un assembly CLR, vous ne pouvez pas créer de instance de l’objet.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour