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.
9  1553 
Can you create a setup package for the dll? Probably your best bet.
Jeff
"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
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" <je**@removeemergencyreporting.com> wrote in message
news:e6**************@TK2MSFTNGP09.phx.gbl... Can you create a setup package for the dll? Probably your best bet.
Jeff
"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
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**************@TK2MSFTNGP09.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\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" <je**@removeemergencyreporting.com> wrote in message
news:e6**************@TK2MSFTNGP09.phx.gbl... Can you create a setup package for the dll? Probably your best bet.
Jeff
"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
> 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**************@TK2MSFTNGP09.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\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" <je**@removeemergencyreporting.com> wrote in message
news:e6**************@TK2MSFTNGP09.phx.gbl... > Can you create a setup package for the dll? Probably your best bet.
>
> Jeff
>
> "Bonj" <Bo**@discussions.microsoft.com> wrote in message
> news:8B**********************************@microsof t.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_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.
>
>
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**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
> 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\msvcr 71.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**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
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**@discussions.microsoft.com> wrote in message
news:2C**********************************@microsof t.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\Microsoft.NET\Framework\v1.1.4322\msvcr 71.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**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
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.Net
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****************@tk2msftngp13.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**@discussions.microsoft.com> wrote in message
news:2C**********************************@microsof t.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\Microsoft.NET\Framework\v1.1.4322\msvcr 71.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**@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.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_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.
"Bonj" <Bo**@discussions.microsoft.com> wrote in message news:<2C**********************************@microso ft.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\Microsoft.NET\Framework\v1.1.4322\msvcr 71.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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Matik |
last post by:
Hi,
I alredy tried to search this problem in last posts, but I couldn't
find the answer.
I try to access via Extended SP the method in a dll.
I registered the dll as a ExSP, with a name of...
|
by: Bruce |
last post by:
Since DBlib is no longer the suggested method for connecting back to
sql server from an Extended Stored Procedure, has anyone built any
extended stored procedures that use other connection methods...
|
by: smauldin |
last post by:
What is the overhead of using extended stored procedures?
I created a table with 500,000 rows.
1) I ran a select on two columns and it runs in about 5 seconds.
2) I ran a select on one column...
|
by: scanner2001 |
last post by:
Here is what I would like to be able to do,
Have an SQL extended stored procedure to do file copy, delete, and
rename(move) procedures.
I have written the code in C# to do this, in the form of a...
|
by: scanner2001 |
last post by:
I am writing an extended stored procedure in c++ 7. As I have been
testing, I am able to run this on my local box, my local sql server. When I
register the extended stored procedure on a different...
|
by: icebrrrg |
last post by:
Hi. I have some functionality in a C# DLL that I would like to be able
to call from inside SQLServer. I know this was possible in C++, using
an Extended Stored Procedure, but I haven't been able to...
|
by: SSW |
last post by:
Hi:
I'm trying to run Extended stored procedure, which is written in VC++ in
window 2000 Professional. It works fine.
But when I run it in windows 2003 I get following error
ODBC: Msg 0,...
|
by: Bonj |
last post by:
Hi
I'm looking to write an extended stored procedure, the job of which will
basically to read data from one table, process it using a COM object, and
write (insert) rows out to another table.
I...
|
by: ppateel |
last post by:
Hi,
First I would like to apologize for cross posting in three groups as
I did not know which one would be the appropriate group. If some one
points me to the correct one I will use that in the...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
