Extended stored procedure

[Bonj]

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_addextended proc" 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" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...

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_addextended proc" 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.

[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\bi nn" 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" <je**@removeeme rgencyreporting .com> wrote in message
news:e6******** ******@TK2MSFTN GP09.phx.gbl...

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

Jeff

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...

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_addextended proc"
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]

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" <benjtaylor at hotpop d0t com> wrote in message
news:#A******** ******@TK2MSFTN GP09.phx.gbl...

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\bi nn" 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" <je**@removeeme rgencyreporting .com> wrote in message
news:e6******** ******@TK2MSFTN GP09.phx.gbl...

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

Jeff

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...

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_addextended proc"
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.

[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...?


Jeff

"Bonj" <benjtaylor at hotpop d0t com> wrote in message
news:#A******** ******@TK2MSFTN GP09.phx.gbl...

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\bi nn" 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" <je**@removeeme rgencyreporting .com> wrote in message
news:e6******** ******@TK2MSFTN GP09.phx.gbl...

> Can you create a setup package for the dll? Probably your best bet.
>
> Jeff
>
> "Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
> news:8B******** *************** ***********@mic rosoft.com...
>> 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_addextended proc"
>> 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.
>
>

[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++

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...

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_addextended proc" 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.

[Bonj]

> 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\Micr osoft.NET\Frame work\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
Visual C++

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...

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_addextended proc" 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.

[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

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:2C******** *************** ***********@mic rosoft.com...

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\Micr osoft.NET\Frame work\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
Visual C++

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...

> 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_addextended proc"
> 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.

[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/

Ge***@SQLDev.Ne t

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.

"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

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

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:2C******** *************** ***********@mic rosoft.com...

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\Micr osoft.NET\Frame work\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
Visual C++

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message
news:8B******** *************** ***********@mic rosoft.com...
> 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_addextended proc"
> 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.

[Arnaud Debaene]

"Bonj" <Bo**@discussio ns.microsoft.co m> wrote in message news:<2C******* *************** ************@mi crosoft.com>...

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\Micr osoft.NET\Frame work\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