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.