Extended stored procedure

[Guest]

Hello

I am having an issue that I've been having for months, whereby I can't get
*ANY* extended stored procedure to run on the PC other than the one I
developed it on.
The ones I have tested have all got exactly the same SQL server
configuration (default installation of MSDE). "sp_addextendedproc" appears to
run without error, but on invoking the xp, I get the error:
Cannot load the DLL testproc.dll, or one of the DLLs it references. Reason:
126(error not found).

I've posted to this effect before, and all I got suggested was check all the
dependencies are installed on the target machine. Which is helpful to be
reminded of, but now I've checked that they all are. It still gives the error
even if I don't add any code to the project - just build it with the skeleton
that the wizard gives you.

Could somebody with SQL server possibly give it a test to see if they can do
what I'm trying to do? It really is very simple what I'm trying to do... I
must stress that this deployment nightmare *still* occurs with just the
wizard-generated skeleton... and other than being windows 2000 as opposed to
XP, the target machines are identical to the development machine (well,
they're obviously not, but to my understanding they are.). It's just nailing
down how they're different - any ideas?

I'm sure it's just some DLL I haven't taken into account, but I can't think
what.
opends60.dll and all the standard runtime libraries such as msvcrt.dll etc.
are all there.

 

[Jeff Dillon]

Can you create a setup package for the dll? Probably your best bet.

Jeff

 

[Bonj]

mmmm... maybe, i'll try it.
The DLL has to be installed into SQL server's binn directory though - would
you know if there is an automatic way to do that?
There probably isn't, and I'll just have to hardcode
"%programfiles%\microsoft sql server\mssql\binn" as the install path... or
is it OK installed to a different path?
I did dumpbin /dependents on the DLL, and it gave me three dependencies:
kernel32.dll (obviously), opends60.dll (the db library), and msvcr71d.dll.
Hmmm... the VC runtime, of course - but was that installed on the target
machine? No, msvcr71d.dll wasn't as it's the debug version, so I did a
release build and then dumpbin confirmed that it now depended on msvcr71.dll
instead, which *was* installed on the target machine (in .NET framework's
directory) - but still to no avail! I thought I'd solved it then, but no. It
was not to be!

any further ideas greatly appreciated though!

 

[Jeff Dillon]

Maybe you'll try it? Why look for other ideas till you do?

Create an install package, and install it.

Then move the dll to the binn directory, and run regsvr32 on it

Jeff

 

[Bonj]

Maybe you'll try it? Why look for other ideas till you do?

Well, I will. When I'm back at work.

Create an install package, and install it.
OK.


Then move the dll to the binn directory, and run regsvr32 on it

I thought this was only necessary for COM DLLs? Surely an extended stored
procedure isn't a COM DLL...?

 

[Ronald Laeremans [MSFT]]

How did you ascertain all dependencies where there?

2 suggested tools are regmon from systems internals or depends.exe (from
Microsoft) in profile mode.

In my personal experience (of investigating a 100+ of these reports) I have
never seen this error turn out to be false. Of course there is always the
chance that this is the first one.

Ronald Laeremans
Visual C++

 

[Guest]

How did you ascertain all dependencies where there?

kernel32.dll must be for the computer to function at all.
opends60.dll was in SQL server's binn directory.
I found out that msvcr71.dll was in dotnet framework's installation
directory by doing
dir c:\msvcr71.dll /s /b
and got back

c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\msvcr71.dll

In my personal experience (of investigating a 100+ of these reports) I have
never seen this error turn out to be false. Of course there is always the
chance that this is the first one.

No - it's not a "false" error. I am not sure, but I think at the moment that
the error is due to msvcr71.dll not being in SQL server's binn directory, as
I tried it *with* that, and it worked. So fingers crossed it still will when
I install it and test it

 

[Ronald Laeremans [MSFT]]

Using either of the tools I mentioned is probably a faster way (it shows
what is being probed for where) than trial and error. ;-)

Ronald

 

[Gert E.R. Drapers]

As Ronald says, DEPENDS.EXE is the best way to attack this problem, it is
the only thing I ever use in these cases.
See http://www.dependencywalker.com/

(e-mail address removed)

Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.

 

[Arnaud Debaene]

kernel32.dll must be for the computer to function at all.
opends60.dll was in SQL server's binn directory.
I found out that msvcr71.dll was in dotnet framework's installation
directory by doing
dir c:\msvcr71.dll /s /b
and got back

c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\msvcr71.dll

Ok, but is this directory in the PATH of SQL Server? See the
LoadLibrary documentation to learn how and where exactly DLLs are
searched.

Another idea is that there may be a dynamic dependency with another
DLL (that is loaded - directly or indirectly - by LoadLibrary).
Dumpbin won't give you these dependencies : you need to check them at
run-time (with depends in profinlg mode for example, as already
suggested).

Arnaud
MVP - VC