INF: Calling DLLs from Extended Stored Procedures

ID: Q108163

The information in this article applies to:

Microsoft SQL Server version 4.2x

SUMMARY

When calling extended stored procedures from SQL Server, the main DLL and all the DLLs which are being called from the extended store procedure need to be on the path during the startup of SQL Server. Otherwise, when an attempt is made to execute the extended stored procedure, you will get a message saying,

Can not find the DLL 'mydll.dll'

where mydll is the name of the extended stored proc DLL.

MORE INFORMATION

This problem commonly occurs when using dynamically linked C runtime libraries. The file name for Win32 SDK dynamic C runtime library was CRTDLL.DLL (import library CRTDLL.LIB), which comes with the Windows NT operating system. The file name for Visual C++ for Windows NT dynamic C runtime library is MSVCRT10.DLL (import library MSVCRT.LIB), which does NOT come with the operating system. (Therefore, the Independent Software Vendors (ISVs) would have to distribute it with their extended stored procedures.)

If a developer chooses to use the dynamic C runtime library for extended stored procedure DLLs compiled under Microsoft Visual C++, MSVCRT10.DLL is needed on the path during program execution.

NOTE: A program started as a system service will have a different path than one started as a user process. This path, called system path, is one of system environment variables and can be examined using the System applet in the Control Panel.

For example, if SQL Server is being started as a system service and you have extended stored procedures that are linked with MSVCRT.LIB, MSVCRT10.DLL needs to be somewhere on the NT system path.

Additional query words: 4.20 Windows NT

Keywords : kbother kbtshoot SSrvTran_SQL
Version : 4.2
Platform : WINDOWS
Issue type :