| Groups | Blog | Home |
visual c : Extended stored procedure
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.
Can you create a setup package for the dll? Probably your best bet.
Jeff [quoted text, click to view] "Bonj" <Bonj@discussions.microsoft.com> wrote in message news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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 [quoted text, click to view] "Bonj" <benjtaylor at hotpop d0t com> wrote in message news:#Acn84dvEHA.3416@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" <jeff@removeemergencyreporting.com> wrote in message > news:e6gr9zcvEHA.3976@TK2MSFTNGP09.phx.gbl... > > Can you create a setup package for the dll? Probably your best bet. > > > > Jeff > > > > "Bonj" <Bonj@discussions.microsoft.com> wrote in message > > news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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! [quoted text, click to view] "Jeff Dillon" <jeff@removeemergencyreporting.com> wrote in message news:e6gr9zcvEHA.3976@TK2MSFTNGP09.phx.gbl... > Can you create a setup package for the dll? Probably your best bet. > > Jeff > > "Bonj" <Bonj@discussions.microsoft.com> wrote in message > news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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. > >
[quoted text, click to view]
> Maybe you'll try it? Why look for other ideas till you do? Well, I will. When I'm back at work. [quoted text, click to view] > > Create an install package, and install it. OK. [quoted text, click to view] > > 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...? [quoted text, click to view] > > Jeff > > "Bonj" <benjtaylor at hotpop d0t com> wrote in message > news:#Acn84dvEHA.3416@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" <jeff@removeemergencyreporting.com> wrote in message >> news:e6gr9zcvEHA.3976@TK2MSFTNGP09.phx.gbl... >> > Can you create a setup package for the dll? Probably your best bet. >> > >> > Jeff >> > >> > "Bonj" <Bonj@discussions.microsoft.com> wrote in message >> > news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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++ [quoted text, click to view] "Bonj" <Bonj@discussions.microsoft.com> wrote in message news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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.
[quoted text, click to view]
> 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 [quoted text, click to view] > 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 [quoted text, click to view] >
> Ronald Laeremans > Visual C++ > > "Bonj" <Bonj@discussions.microsoft.com> wrote in message > news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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 [quoted text, click to view] "Bonj" <Bonj@discussions.microsoft.com> wrote in message news:2CD7F58E-2D85-43CB-AF66-947B1509F839@microsoft.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\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" <Bonj@discussions.microsoft.com> wrote in message >> news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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/ GertD@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. [quoted text, click to view] "Ronald Laeremans [MSFT]" <ronaldl@online.microsoft.com> wrote in message news:%23k$ojjawEHA.2976@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" <Bonj@discussions.microsoft.com> wrote in message > news:2CD7F58E-2D85-43CB-AF66-947B1509F839@microsoft.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\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" <Bonj@discussions.microsoft.com> wrote in message >>> news:8BCE871C-2847-4638-82FD-14B21F93FA91@microsoft.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. >>> >>> >>> > >
[quoted text, click to view]
"Bonj" <Bonj@discussions.microsoft.com> wrote in message news:<2CD7F58E-2D85-43CB-AF66-947B1509F839@microsoft.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\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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |