Cómo ejecutar un objeto COM basado en DLL fuera del proceso de SQL Server

Seleccione idioma Seleccione idioma
Id. de artículo: 198891 - Ver los productos a los que se aplica este artículo
Este artículo se publicó anteriormente con el número E198891
Expandir todo | Contraer todo

En esta página

Resumen

Microsoft SQL Server 6.5 o posterior proporciona la capacidad de cargar y ejecutar objetos personalizados del Modelo de objetos componentes (COM) a través de un conjunto de procedimientos almacenados de automatización OLE o a través de procedimientos almacenados extendidos. De manera predeterminada, los objetos COM basados en DLL se cargan como en un servidor de procesos, lo que significa que no sólo se cargan dentro del espacio de la dirección de memoria del proceso de SQL Server, sino que tienen acceso total a dicho espacio. Por lo tanto, un objeto COM cargado en el espacio de procesos de SQL Server debe adoptar las mismas reglas que cualquier archivo DLL. Existe un riesgo potencial de que un objeto COM sobrescriba memoria dentro del proceso de SQL Server o produzca pérdida de recursos, lo que causaría inestabilidad.

Si hay sospechas de que un objeto COM puede afectar a la solidez del proceso de SQL Server, quizá prefiera usar los pasos descritos en este artículo para crear una instancia el objeto COM fuera del espacio de proceso de SQL Server. La implementación de la especificación del Modelo de objetos componentes distribuido (DCOM) de "Transparencia de localización" en el sistema operativo ha permitido ejecutar un objeto COM basado en DLL fuera del espacio de proceso de SQL Server.

El proceso de ejecutar un objeto COM basado en DLL fuera del espacio de dirección de la aplicación principal es remoto. Los servicios remotos requieren que otro ejecutable sea un proceso suplente en lugar del ejecutable de SQL Server. El ejecutable predeterminado utilizado por el Administrador de control de servicios de DCOM (Rpcss.exe) se llama Dllhost.exe. La estructura de compatibilidad con DCOM usa el archivo Dllhost.exe para cargar la DLL en su espacio de procesos y, a continuación, usa pares de servidor proxy y auxiliar para calcular que la interfaz requerida vuelva al cliente, como es el caso de SQL Server. Este ejecutable puede aceptar varias solicitudes de interfaz o método a la vez. Una vez terminado el uso de la interfaz, el Administrador de control de servicios (SCM) de DCOM administra la limpieza y la descarga del archivo Dllhost.exe. No debe esperarse que los objetos COM retengan información de estado entre las instancias.

Para que este artículo funcione correctamente, el sistema tiene que utilizar un sistema operativo compatible con DCOM. Podría ser Microsoft Windows NT 4.0 Service Pack 2 o posterior, Microsoft Windows 98 o Microsoft Windows 95 con el complemento DCOM instalado. Los pasos siguientes se pueden aplicar a cualquier objeto COM basado en DLL que se esté creando en el espacio de proceso de SQL Server, independientemente de si se está creando la instancia a través de sp_OACreate o de un procedimiento almacenado extendido.

Más información

A continuación se muestra información sobre los dos métodos básicos que se puedan usar para crear una instancia del objeto COM fuera del proceso.

El cliente COM solicita servicios remotos del objeto

Si cambia la manera de invocar al objeto COM, puede solicitar que éste se cree fuera del espacio de dirección de SQL Server.
  • Si el objeto COM se carga utilizando el procedimiento sp_OACreate, se cargará de manera predeterminada en el proceso. Sin embargo, hay un tercer parámetro opcional a este procedimiento que se puede utilizar para indicar el contexto de dónde crear el objeto. Si no se especifica este parámetro, se usa el valor predeterminado de cinco (5), lo que implica ejecutar el objeto tanto dentro como fuera del proceso. Debe cambiar el parámetro a cuatro (4), lo que indica a DCOM que este componente se va a ejecutar como un ejecutable local. Use una sintaxis similar al ejemplo siguiente para indicar explícitamente a DCOM que ejecute el objeto COM "fuera del proceso" usando el procedimiento sp_OACreate almacenado:
       DECLARE @object int DECLARE @hr int EXEC @hr = sp_OACreate 'SQLOLE.SQLServer', @object OUT, 4
    						
  • Si el objeto COM se crea dentro de un procedimiento almacenado extendido, el tercer parámetro de CoCreateInstance o CoCreateInstanceEx se puede cambiar a CLSCTX_LOCAL_SERVER. Esto se muestra en el ejemplo de código siguiente utilizando CoCreateInstance:
       HRESULT hr = CoCreateInstance(CLSID_Test, NULL, CLSCTX_LOCAL_SERVER, IID_IUnknown, (void**)&piunknown);
    						

Modificar el Registro para forzar el servicio remoto del objeto

Si no puede modificar el cliente COM para solicitar que el objeto se cree fuera del proceso, existen dos métodos diferentes de forzar dicha acción.
  • Use el visor de objetos OLE/COM (Oleview.exe) que se incluye con Microsoft Visual C++ y localice el objeto ProgID con el formato OLEComponente.Objeto bajo All Objects. Seleccione el objeto COM y, a continuación, en el menú Object, seleccione CoCreateInstance Flags. Asegúrese de que sólo se ha seleccionado CLSCTX_LOCAL_SERVER. A continuación, bajo las fichas Implementation e Inproc Server, seleccione Use Surrogate Process y deje sin activar "Path to Custom Surrogate", que permite que se cargue el archivo Dllhost.exe y que la DLL de COM se incluya en su espacio de proceso.

    Si no tiene Microsoft Visual C++, la utilidad Visor de objetos OLE/COM se puede descargar también del siguiente sitio Web de Microsoft:
    http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=es
  • Utilice los pasos siguientes para actualizar manualmente el Registro.

    Advertencia
    Pueden producirse graves problemas si modifica incorrectamente el Registro mediante el Editor del Registro o con cualquier otro método. Estos problemas pueden requerir que reinstale el sistema operativo. Microsoft no puede garantizar la solución de esos problemas. Modifique el Registro bajo su responsabilidad.
    1. Obtenga el identificador de clase (CLSID) del objeto COM. El CLSID es un número de 128 bits y se considera un identificador único global (GUID) que se usa para identificar de forma exclusiva el componente, módulo o archivo que contiene este objeto COM. Cuando se crean objetos COM usando los procedimientos almacenados de automatización OLE, el primer parámetro del procedimiento almacenado es un identificador de programa, o se utiliza el ProgID del objeto OLE para derivar el CLSID. Esta cadena de caracteres describe la clase del objeto OLE y tiene la forma siguiente:
            OLEComponente.Objeto
      								
      Puede usar el identificador de programa para encontrar el identificador de clase para un objeto COM.

      Abra el Editor del Registro (Regedit.exe) y bajo la clave HKEY_CLASSES_ROOT use el método Find para localizar una clave con el nombre de su <OLEComponent.Objet>. Lo encontrará en otros niveles, pero debería estar ubicado en el nivel inmediatamente inferior a HKEY_CLASSES_ROOT. Tras localizar la clave, expanda la carpeta y encontrará una subclave llamada CLSID. Haga clic en esa carpeta para ver los valores incluidos en dicha clave. En el lado derecho de la pantalla verá un valor llamado "(Predeterminado)". Los datos para esa clave deben tener el formato siguiente:
            {59F929A0-74D8-11D2-8CBC-08005A390B09}
      								
      Anote el nombre de este valor o cópielo en el Bloc de notas. Incluya los corchetes.
    2. Vaya hasta la clave HKEY_CLASSES_ROOT\CLSID y encuentre la subclave con este número GUID. Después de resaltar la clave HKEY_CLASSES_ROOT\CLSID puede usar la función Buscar del Editor del Registro (en el menú Edición) y pegar el GUID en el cuadro de diálogo Buscar. Asegúrese de que ha encontrado la interfaz adecuada examinando la subclave InprocServer32 situada bajo esta clave, que indica la ubicación de su archivo DLL COM. Si hay una clave TypeLib, compruebe este valor GUID. Éste debe ser diferente que el anotado en el paso 1. En caso contrario, tiene el GUID de TypeLib y no el GUID para el objeto COM. La subclave ProgID tendrá un valor de 'OLEComponente.Objeto.1'. El valor que aparece al final es sólo para este ejemplo y se utiliza para proporcionar información de versiones.
    3. Asegúrese de que bajo la subclave InprocServer32 del GUID hay un valor ThreadingModel y que está establecido como Both o Free para asegurarse de que el cálculo de referencias comprende el modelo de subprocesamiento del objeto COM para permitir la ejecución de COM fuera del espacio de procesos de SQL Server. Si no hay un valor ThreadingModel o si está establecido como Apartment, puede que la creación de instancias del objeto COM no sea coherente.

      Nota
      Si agrega el valor ThreadingModel asegúrese de probar su objeto COM antes de implementarlo.
    4. Resalte el número o subclave GUID que aparece bajo la clave HKEY_CLASSES_ROOT\CLSID. En el menú Edición, haga clic en Nuevo y seleccione Valor de cadena. En la columna Nombre, escriba lo siguiente:
      AppID
    5. Presione ENTRAR e inserte como valor el identificador de clases o el número GUID anotado en el paso 1. El GUID debe aparecer entre llaves como en el ejemplo siguiente:
       
            {59F929A0-74D8-11D2-8CBC-08005A390B09} 
      
      								
      El identificador AppID de la aplicación lo utiliza DCOM para asociar la DLL con un archivo ejecutable.
    6. Agregue una subclave nueva bajo HKEY_CLASSES_ROOT\AppID y asigne como nombre el mismo identificador de clase o número GUID insertando llaves como en el paso anterior.
    7. Resalte el nombre GUID. En el menú Edición, haga clic en Nuevo y seleccione Valor de cadena. En la columna Nombre, escriba lo siguiente:
      DllSurrogate
      Deje en blanco la columna Datos para este valor. Como la columna de datos está vacía, DCOM ejecuta el archivo ejecutable, Dllhost.exe, y carga el objeto COM dentro de su espacio de proceso.
    8. Cierre el Editor del Registro. Haga clic en Inicio y, a continuación, haga clic en Ejecutar. En el cuadro de diálogo Ejecutar, escriba lo siguiente:
      DCOMCNFG
      Presione la tecla ENTRAR para abrir el cuadro de diálogo Propiedades de configuración de COM distribuido. Haga clic en la ficha Propiedades predeterminadas y asegúrese de que está activada la casilla de verificación Habilitar COM distribuido en este equipo. Si no lo está, actívela y, a continuación, haga clic en Aplicar.
    9. Asegúrese de que la cuenta de usuario de Microsoft Windows NT que ejecuta SQL Server tiene permiso "Control total" en las claves del Registro para este objeto. Si los permisos no son suficientes o las claves del Registro se escriben incorrectamente, pueden aparecer los errores siguientes al crear el objeto COM:
      Información de error de automatización OLE
      HRESULT: 0x80040154
      Origen: procedimiento extendido ODSOLE
      Descripción: clase no registrada

      Información de error de automatización OLE
      HRESULT: 0x80070005
      Origen: procedimiento extendido ODSOLE
      Descripción: acceso denegado

      Información de error de automatización OLE
      HRESULT: 0x80080005
      Origen: procedimiento extendido ODSOLE
      Descripción: error en la ejecución de servidor
    10. Compruebe que el archivo Dllhost.exe se está ejecutando y que carga el objeto el objeto COM en su espacio de proceso. Esto requiere que el Kit de recursos de Microsoft Windows NT esté en el equipo con Windows NT en el que se ejecuta SQL Server. Abra el símbolo del sistema y ejecute desde éste el archivo Tlist.exe, que muestra todos los procesos y sus identificadores de proceso (PID) asociados. En la secuencia de comandos de Transact-SQL donde se ejecuta sp_OACreate y después de que se ejecute dicha llamada, pero antes de que finalice la secuencia de comandos, use lo siguiente para retardar la finalización de la secuencia de comandos unos 20 segundos adicionales:
      WAITFOR DELAY '000:00:20'
      								
      Ejecute la secuencia de comandos e inmediatamente vaya al símbolo del sistema y ejecute el archivo Tlist.exe. Anote el PID de Dllhost.exe. Vuelva a ejecutar el archivo Tlist.exe y pase el PID como un parámetro. Esto muestra las DLL que se cargan dentro del espacio de proceso de Dllhost.exe. El objeto COM basado en DLL se debería mostrar ejecutándose dentro de este proceso. Una vez que regresa la secuencia de comandos, ejecutar Tlist.exe de nuevo revela que el proceso de Dllhost.exe ya no se está ejecutando.

      En el ejemplo siguiente, el objeto ADODB.Connection se crea fuera del espacio de proceso de SQL Server. Esta instantánea que usa Tlist.exe se realizó mientras el objeto COM existía en el espacio de proceso de Dllhost.exe. Tenga en cuenta que se carga el módulo Msado15.dll, que es el módulo que contiene el objeto COM.
      C:\>tlist dllhost 275 dllhost.exe CWD:     C:\NT40\system32\ CmdLine: C:\NT40\System32\dllhost.exe {00000514-0000-0010-8000-00AA006D2EA4} -Embedding VirtualSize:    19180 KB   PeakVirtualSize:    19180 KB WorkingSetSize:  1780 KB   PeakWorkingSetSize:  1780 KB NumberOfThreads: 3 278 Win32StartAddr:0x01001920 LastErr:0x00000000 State:Waiting 215 Win32StartAddr:0x00001b5e LastErr:0x00000000 State:Waiting 253 Win32StartAddr:0x00001b60 LastErr:0x000000cb State:Waiting 4.0.1381.105 shp  0x01000000  dllhost.exe 4.0.1381.130 shp  0x77f60000  ntdll.dll 4.0.1381.121 shp  0x77dc0000  ADVAPI32.dll 4.0.1381.133 shp  0x77f00000  KERNEL32.dll 4.0.1381.133 shp  0x77e70000  USER32.dll 4.0.1381.115 shp  0x77ed0000  GDI32.dll 4.0.1381.131 shp  0x77e10000  RPCRT4.dll 4.0.1381.117 shp  0x77b20000  ole32.dll 6.0.8267.0 shp  0x78000000  MSVCRT.dll 0x1f310000  msado15.dll 2.30.4265.1 shp  0x766f0000  OLEAUT32.dll 4.0.1381.72 shp  0x77bf0000  rpcltc1.dll
      								
      Con SQL Server 7.0 Desktop Edition ejecutándose en estaciones de trabajo con Microsoft Windows 95 o Microsoft Windows 98, se puede utilizar durante la ejecución la herramienta "Módulos de 32 bits cargados" dentro de la aplicación Información del sistema de Microsoft para ver la carga o descarga del archivo Dllhost.exe y de la DLL del objeto COM durante esta prueba. Para tener acceso a la herramienta, haga clic en Inicio, seleccione Programas, Accesorios y, a continuación, haga clic en Herramientas del sistema.
Nota
Debido a limitaciones de seguridad, Windows 95 y Windows 98 no admiten que un cliente remoto inicie un proceso DLLSurrogate y cargue una DLL COM. Por lo tanto, el objeto COM tiene que existir dentro de la Tabla de objetos en ejecución (ROT, Running Object Table) y estar ejecutándose o cargado para que pueda utilizarlo un equipo cliente remoto. Puede usar los pasos descritos en este artículo para poder aislar los objetos COM sospechosos de causar inestabilidad en SQL Server. Asegúrese de que se prueba cada componente detenidamente ejecutándolo fuera del proceso para garantizar un comportamiento coherente. La diferencia de rendimiento a la hora de crear instancias de un objeto COM dentro del proceso de SQL Server y fuera del espacio de proceso varía. Asimismo, algunos objetos COM no se integraron para ser remotos y pueden producir pérdida de recursos. Pruebe detenidamente antes de implementar los pasos descritos en este artículo para algo distinto a un paso de solución de problemas. El siguiente artículo de Microsoft Knowledge Base incluye un ejemplo de cómo utilizar un objeto COM para servicio remoto puede producir una pérdida de recursos:
197426 REVISIÓN: Pérdida de identificadores al pasar objetos ADO entre procesos
Nota
De manera predeterminada, Microsoft SQL Server 6.5 funciona con un modelo de Subproceso controlado único (STA) y se ocupa de la inicialización de los objetos COM en un subproceso interno independiente. En este modelo, se selecciona un subproceso para controlar la creación de todos los objetos OLE dentro del proceso de SQL Server y para que vuelvan al proxy todas las conexiones cliente que necesitan acceso a este objeto COM. Como esto lo trata internamente SQL Server, no se puede garantizar la persistencia del objeto entre instancias del objeto COM.

Referencias

Para obtener más información acerca del modelo de objetos COM de SQL Server 6.5, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
194661 Modelo de persistencia de objetos COM de SQL Server
Para obtener más información acerca de cómo se implementa el procedimiento almacenado Sp_OA, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
180780 Cómo se implementa la extensión de procedimientos Sp_OA en SQL Server
Para obtener más información sobre la ejecución de objetos COM basados en DLL dentro de suplentes de DLL, consulte la siguiente documentación (en inglés):

Eddon, Guy; Eddon Henry, Inside Distributed Com (Mps). Microsoft Press, 1998, (ISBN 1-57231-849-X), Capítulo ocho: 'DLL Surrogates and Executable Components' (Suplentes de DLL y componentes ejecutables)

Box, Don, Essential COM. Addison-Wesley Pub. Co., (ISBN 0-201-63446-5) Capítulo seis: 'Applications' (Aplicaciones) Grimes, Richard, Professional DCOM Programming. Wrox Press Inc. (ISBN 1-861000-60-X), Capítulo cuatro: 'Distributed Component Object Model' (Modelo de objetos componentes distribuido (DCOM98)) El complemento DCOM para Windows 95 se incluye con el medio que contiene SQL Server 7.0 y el archivo se llama Dcom95.exe. Puede descargar Dcom95.exe del siguiente sitio Web:
http://www.microsoft.com/com

Propiedades

Id. de artículo: 198891 - Última revisión: martes, 26 de diciembre de 2006 - Versión: 9.1
La información de este artículo se refiere a:
  • Microsoft SQL Server 6.5 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Palabras clave: 
kbinfo KB198891

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com