?????? ??????This article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.
By changing the way that you invoke the COM object, you can request that the object be created outside of the SQL Server address space.
If the COM object is loaded by using thesp_OACreateprocedure, by default it is loaded in process. However, there is an optional third parameter to this procedure that may you can use to indicate the context of where to create the object. If this parameter is not specified, the default setting of five (5) is used, which means to run the object either inside or outside of the process. You need to change the parameter to four (4), which indicates to DCOM that this component is to run as a local executable. Use syntax that is similar to the following example to explicitly inform DCOM to run the COM object "out of process" using thesp_OACreatestored procedure:
DECLARE @object int
DECLARE @hr int
EXEC @hr = sp_OACreate 'SQLOLE.SQLServer', @object OUT, 4
If the COM object is created within an extended stored procedure the third parameter ofCoCreateInstance??,CoCreateInstanceExcan be changed to CLSCTX_LOCAL_SERVER. This is shown in the following code sample usingCoCreateInstance:
If you cannot modify the COM client to request that the object be created out of process, two different methods exist to force the object to be created out of process.
Use the OLE/COM Object viewer (Oleview.exe) that is shipped with Microsoft Visual C++ and locate the ProgID in the form of OLEComponent.Object underAll Objects. Select the COM object, and then from the????????????, ?? ??? ????CoCreateInstance Flags. Make sure that only CLSCTX_LOCAL_SERVER is selected. Next,
under theImplementation, ??Inproc Servertabs selectUse Surrogate Processand leave the "Path to Custom Surrogate" blank, which allows the Dllhost.exe file to be loaded and the COM DLL brought within it's process space.
If you do not have Microsoft Visual C++, the OLE/COM Object Viewer utility is also available for download from the following Microsoft Web site:
Obtain the Class Identifier (CLSID) of the COM object. The CLSID is a 128-bit number and considered a Globally Unique Identifier (GUID) that is used to uniquely identify the component, module or file that contains this COM object. When creating COM objects using the OLE Automation stored procedures, the first parameter to the stored procedure is a programmatic identifier or the ProgID of the OLE object is used to derive the CLSID. This character string describes the class of the OLE object and has the following form:
OLEComponent.Object
You can use the programmatic identifier to find the class identifier for a COM object.
Open the Registry Editor (Regedit.exe) and under the HKEY_CLASSES_ROOT key use the??????method to locate a key with the name of your<olecomponent.object></olecomponent.object>. You will find it at other levels, but it should be located at the level directly below the HKEY_CLASSES_ROOT. After you locate the key, expand the folder for the key name and you should see a subkey named CLSID. Click that folder to see the values within that key. On the right-hand side of the screen is a title named "(Default)". The data for that key should be in the following form:
{59F929A0-74D8-11D2-8CBC-08005A390B09}
Make a note of this value or copy it to Notepad. Include the brackets.
Navigate under the HKEY_CLASSES_ROOT\CLSID key and find the subkey with this GUID number. After you highlight the HKEY_CLASSES_ROOT\CLSID key you can use the??????function in Registry Editor (under the??????menu) and paste the GUID into the??????????? ????? ?? ??????? ?? ??? ?? .. Make sure that you have found the proper interface by inspecting the InprocServer32 subkey below this key, which points to the location of your COM DLL file. If there is a TypeLib key, check this GUID value. This should be different than what you noted in step 1. Otherwise, you have the TypeLib GUID and not the GUID for the COM object. The ProgID subkey will have a value of 'OLEComponent.Object.1'. The one on the end is for this sample only and is used for versioning information.
While under the GUID's InprocServer32 subkey, make sure that a ThreadingModel value exists and that it is set to either Both or Free to make sure the marshaling understands the threading model of the COM object to enable execution of COM out of SQL Server process space. If there is not a ThreadingModel value or it is set to Apartment, COM object instantiation may not be consistent.
???:If you add the ThreadingModel value make sure that you test your COM object before implementing.
Highlight the GUID number/subkey under the HKEY_CLASSES_ROOT\CLSID key. ???????????? ??,???, ?? ???? ??? ?? ??? ???????????? ???. ?? ??????????column, type the following:
AppID
??? ?????ENTERand then insert the class identifier or GUID number you noted from step 1 as the value. The GUID should be inside the curly brackets as in the following example:
{59F929A0-74D8-11D2-8CBC-08005A390B09}
The application identifier AppID is used by DCOM to associate the DLL with an executable file.
Add a new subkey under the HKEY_CLASSES_ROOT\AppID and set it's name to the same class identifier or GUID number with the brackets as inserted in the preceding step.
Highlight the GUID name. ???????????? ??,???, and then select???????? ???. ?? ??????????column, type the following:
DllSurrogate
???? ???????:column blank for this value. Because the data column is blank, this informs DCOM to run the default executable file, Dllhost.exe and load the COM object within it's process space.
Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email
???? ?????? ????????
????? ?? ???? ????
