INF: Calling DLLs from Extended Stored ProceduresID: Q108163
|
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'
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 :
Last Reviewed: March 18, 1999