locked
SQL 2005 x64 - Missing DLL for extended stored procedures RRS feed

  • Question

  • Hi All -

    I have a SQL 2005 Server x64 (SP3) which is exhibiting something odd compared to other SQL Servers.  Long story short we have an application that relies on several of the extended stored procedures.  On the SQL Server when viewing the General properties of an extended stored procedure in the Master db have a blank for DLL instead of (Server Internal) as my other SQL Servers do.  I have searched high and low and am unsure why this is and what i can do to correct this.  Thanks in advance.

    Tuesday, December 21, 2010 7:02 PM

Answers

  • Hi iberg,

    After checked several extended stored procedures undere <ServerInstnace> -> Databases -> System Databases -> master -> Programmability -> Extended Stored Procedures -> System Extended Stored Procedures, I also find blank for DLL column (such as sp_executesql). It seems normal for system extended stored procedure.

    I am not sure the extended stored procedures you mentioned are system extended stored procedures or user extended stored procedures. If they are system extended stored procedure, can you point out them here? If thery are user extended stored procedure, I think you should be able to change its DLL property via its Properties dialog box. Besides, you can adding an extended stored procedure to SQL Server, for more information you can refer to Adding an Extended Stored Procedure to SQL Server (http://msdn.microsoft.com/en-us/library/ms164653(v=SQL.90).aspx).

    Hope this helps.

    Thanks,
    Chunsong


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Alex Feng (SQL) Wednesday, December 29, 2010 12:20 PM
    Wednesday, December 22, 2010 7:45 AM

All replies

  • Hi iberg,

    After checked several extended stored procedures undere <ServerInstnace> -> Databases -> System Databases -> master -> Programmability -> Extended Stored Procedures -> System Extended Stored Procedures, I also find blank for DLL column (such as sp_executesql). It seems normal for system extended stored procedure.

    I am not sure the extended stored procedures you mentioned are system extended stored procedures or user extended stored procedures. If they are system extended stored procedure, can you point out them here? If thery are user extended stored procedure, I think you should be able to change its DLL property via its Properties dialog box. Besides, you can adding an extended stored procedure to SQL Server, for more information you can refer to Adding an Extended Stored Procedure to SQL Server (http://msdn.microsoft.com/en-us/library/ms164653(v=SQL.90).aspx).

    Hope this helps.

    Thanks,
    Chunsong


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Alex Feng (SQL) Wednesday, December 29, 2010 12:20 PM
    Wednesday, December 22, 2010 7:45 AM
  • Hi Chunsong -

     

    Thank you for the reply.  Specifically i'm looking at sp_xml_preparedocument.  Since this is a system extended stored procedure it will not allow me to define which dll it should use.  Is it possible that this system extended stored procedure is linked to a dll with the installation of other software installed like MSXML or XML parser?  really i'm trying to get to the root cause as to why some systems have a DLL listed as (server internal) and others are blank.

    Thanks

    Iberg

    Monday, January 3, 2011 3:20 PM
  • Hi Iberg,

    I checked one of my server instances (SQL Serer 2008 R2 Enterprise and SQL Server 2008 SP2), the DDL of sp_xml_preparedocument is listed as blank. And when you run the following statement, its dll column is displayed as server internal:

    USE master;
    GO
    EXEC sp_helpextendedproc sp_xml_preparedocument;
    GO
    
    

    You should not worry about these system extended stored procedures since they are maintenanced by SQL Server itself. If you encounter any issue while running system extended stored procedure, please let us know.

    Thanks,
    Chunsong

     


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, January 4, 2011 2:09 AM
  • update:

    I found an interesting scenaro: I have an instance of SQL Server 2005, when I use SQL Server Management Studio (SSMS) 2005 to connect this instance, I can see every system extended stored procedure has a DLL value the same as result of EXEC sp_helpextendedproc <procedure_name>; however when you use SSMS 2008 or SSMS 2008 R2 to connect to this instance (or other 2008/2008 R2 instances), all its DDL property is listed as blank.

    Based on these tests, the DDL properties of these system extended stored procedure are hidden by SQL Server Management Studio 2008 or later. By the way, you can run the following stored procedure to get a specified system extended stored produre name and dll name or all of them:

    -- Return a specified extended stored procedure name and the DLL name
    USE master;
    GO
    EXEC sp_helpextendedproc <procedure_name>;
    GO
    
    -- Return all extended stored procedure names and the DLL names 
    USE master;
    GO
    EXEC sp_helpextendedproc;
    GO
    

    For more information about sp_helpextendedproc, please refer to http://msdn.microsoft.com/en-us/library/ms186854.aspx.

    Thanks,
    Chunsong

     


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, January 4, 2011 2:27 AM