Uso estendido de procedimentos armazenados ou procedimentos armazenados SP_OA para carregar o CLR no SQL Server não é suportado

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 322884
Sumário
Microsoft não suporta o uso do Microsoft Common Language Runtime (incluído com o .NET Framework) para qualquer COM callable wrapper ou Managed Extensions para C++ no Microsoft SQL Server 2005, no Microsoft SQL Server 2000 ou no Microsoft SQL Server 7.0. Essa limitação para suporte refere-se diretamente para o uso de procedimentos armazenados estendidos e para o uso de automação OLE para qualquer carregamento das bibliotecas que você deve carregar para executar em espaço de memória do SQL Server.

SQL Server 2005 e versões posteriores hospedam CLR (Common Language Runtime) e oferecem suporte a procedimentos, funções, disparadores, tipos e agregados são escritos em CLR langauges. Nessas versões, você não é possível carregar o CLR usando proceduress armazenado estendido ou procedimentos sp_OA armazenados.
Mais Informações
O assembly do .NET Framework System.Runtime.InteropServices fornece um ambiente robusto para assemblies chamar código não gerenciado. Entretanto, há várias técnicas discordances entre as implementações internas do CLR e SQL Server:

Threading

Para aumentar o desempenho, o CLR implementa thread armazenamento local. Para obter mais informações sobre problemas que são relacionados ao uso do armazenamento local de thread em procedimentos armazenados estendidos, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
163449Uso do armazenamento local de thread em um procedimento armazenado estendido
190987Como usar procedimentos armazenados estendidos
Além disso, CLR usa somente com base no thread de agendamento e não oferece suporte a agendamento de modo fiber. No entanto, o SQL Server pode usar agendamento de modo fiber. Para configurar essa propriedade, use um dos seguintes métodos:
  • Execute o procedimento sp_configure armazenados usando a opção lightweight pooling .
  • No SQL Server 2000 ou no SQL Server 7.0, você pode configurar essa propriedade no SQL Server Enterprise Manager. Para fazer isso, execute as seguintes etapas:
    1. No Enterprise Manager, expanda Microsoft SQL Servers , expanda SQL Server Group e, em seguida, clique com o botão direito do mouse a instância do SQL Server 2000 ou do SQL Server 7.0.
    2. Na caixa de diálogo Propriedades do SQL Server (Configurar) , clique na guia de processador .
    3. Clique para selecionar a caixa de seleção usar Windows NT fibras .
  • No SQL Server 2005, você pode configurar essa propriedade no SQL Server Management Studio. Para fazer isso, execute as seguintes etapas:
    1. No Management Studio, se conectar à instância do SQL Server 2005.
    2. No Explorador de objetos , clique na instância do SQL Server com o botão direito do mouse e, em seguida, clique em Propriedades .
    3. Na caixa de diálogo Propriedades do servidor , clique em processadores .
    4. Clique para selecionar a caixa de seleção usar o Windows fibras (lightweight pooling) .

Memória

O uso de procedimentos armazenados estendidos e automação OLE ambos executar no espaço de endereço de memória virtual da memória do SQL Server. A memória do SQL Server padrão é apenas uma fração da memória que potencialmente pode usar o SQL Server e CLR concorre com qualquer implementação existente para esses recursos de memória. Para obter mais informações sobre gerenciamento de memória do SQL Server, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
316749Pode não haver memória virtual quando você tem um grande número de bancos de dados no SQL Server

Interoperabilidade COM

Esta seção aborda especificamente o uso de automação OLE no SQL Server e ele se aplica a objetos COM em processo e fora de processo. Metadados de assembly de função interfaces implementa um mecanismo fortemente tipados para qualquer invocações.

Como parte desse design, o COM callable wrapper para um assembly deve usar um mecanismo externo de mapear um ClassID para um membro de uma classe gerenciada. Devido a esse mapeamento explícito, não há nenhuma capacidade de uma perspectiva não gerenciada para estabelecer uma lista raiz de interfaces disponíveis.

O procedimento armazenado estendido sp_oaCreate usa a interface IUnknown::QueryInterface para determinar o suporte do objeto para uma determinada interface. A interoperabilidade entre código não gerenciado e CLR depende a interface IDispatch para implementar interfaces. Como não há nenhum equivalente para um método de QueryInterface para um assembly baseado em CLR, você não pode criar uma instância do objeto.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 322884 - Última Revisão: 07/30/2007 16:20:52 - Revisão: 8.2

Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft Common Language Runtime (included with the .NET Framework 1.1)

  • kbmt kbinfo KB322884 KbMtpt
Comentários