deploying extended stored proc

Hi
I have written an extended stored procedure DLL, thanks to the people who
helped me on this.
however i wonder if anyone could shed any light on my deployment issues that
I'm having with it.
Basically, I built it on my XP development PC with VC7.1. I can deploy it on
this PC's local default instance of MSDE without problems. It uses no managed
code whatsoever, and is compiled without /clr. Totally unmanaged.
I am trying to deploy it to a different PC with Win2K, and again - a local,
default, instance of MSDE. I copied it to C:\program files\microsoft sql
server\mssql\binn just as on my pc, added it using "sp_addextendedproc
'xp_myproc', 'xp_myproc.dll'", but it gave the error:
ODBC: Msg 0, Level 16, State 1
Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
126(error not found).
The only thing I can think to be different is that one's got Win2000,
whereas my dev. PC has got XP. This shouldn't matter though, should it?
I checked that the names are the correct case, correct names of the
procedure and the DLL filename and everything.
What could be wrong?
ThanksSorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
server?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bonj" <Bonj@.discussions.microsoft.com> wrote in message
news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> Hi
> I have written an extended stored procedure DLL, thanks to the people who
> helped me on this.
> however i wonder if anyone could shed any light on my deployment issues that
> I'm having with it.
> Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> this PC's local default instance of MSDE without problems. It uses no managed
> code whatsoever, and is compiled without /clr. Totally unmanaged.
> I am trying to deploy it to a different PC with Win2K, and again - a local,
> default, instance of MSDE. I copied it to C:\program files\microsoft sql
> server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> ODBC: Msg 0, Level 16, State 1
> Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> 126(error not found).
> The only thing I can think to be different is that one's got Win2000,
> whereas my dev. PC has got XP. This shouldn't matter though, should it?
> I checked that the names are the correct case, correct names of the
> procedure and the DLL filename and everything.
> What could be wrong?
> Thanks
>|||Nope. Like I say, the following is true of both dev machine, and deployment
target:
There's only one, default, instance of SQL Server (MSDE) on the machine. The
path of the binaries is
c:\program files\microsoft sql server\mssql\binn
and this is the only location where sqlservr.exe is found on the machine.
"Tibor Karaszi" wrote:
> Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> server?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > Hi
> > I have written an extended stored procedure DLL, thanks to the people who
> > helped me on this.
> > however i wonder if anyone could shed any light on my deployment issues that
> > I'm having with it.
> > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > this PC's local default instance of MSDE without problems. It uses no managed
> > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > ODBC: Msg 0, Level 16, State 1
> > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > 126(error not found).
> >
> > The only thing I can think to be different is that one's got Win2000,
> > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> >
> > I checked that the names are the correct case, correct names of the
> > procedure and the DLL filename and everything.
> >
> > What could be wrong?
> >
> > Thanks
> >
>
>|||I see, it was only a wild guess...
Re-reading the error message, it can also be that the DLL you produced in return references some
other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
here... :-\).
I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
problem might be. Perhaps some of the VC persons can pick up on that. ;-)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bonj" <Bonj@.discussions.microsoft.com> wrote in message
news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> Nope. Like I say, the following is true of both dev machine, and deployment
> target:
> There's only one, default, instance of SQL Server (MSDE) on the machine. The
> path of the binaries is
> c:\program files\microsoft sql server\mssql\binn
> and this is the only location where sqlservr.exe is found on the machine.
>
> "Tibor Karaszi" wrote:
> > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> > server?
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > Hi
> > > I have written an extended stored procedure DLL, thanks to the people who
> > > helped me on this.
> > > however i wonder if anyone could shed any light on my deployment issues that
> > > I'm having with it.
> > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > this PC's local default instance of MSDE without problems. It uses no managed
> > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > ODBC: Msg 0, Level 16, State 1
> > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > 126(error not found).
> > >
> > > The only thing I can think to be different is that one's got Win2000,
> > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > >
> > > I checked that the names are the correct case, correct names of the
> > > procedure and the DLL filename and everything.
> > >
> > > What could be wrong?
> > >
> > > Thanks
> > >
> >
> >
> >|||Like I say, it does it the same with a 'blank' extended stored procedure...
i.e. just let the wizard create one, don't add any code, and compile. That
doesn't work on it either.
"Tibor Karaszi" wrote:
> I see, it was only a wild guess...
> Re-reading the error message, it can also be that the DLL you produced in return references some
> other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
> here... :-\).
> I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
> problem might be. Perhaps some of the VC persons can pick up on that. ;-)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> > Nope. Like I say, the following is true of both dev machine, and deployment
> > target:
> > There's only one, default, instance of SQL Server (MSDE) on the machine. The
> > path of the binaries is
> > c:\program files\microsoft sql server\mssql\binn
> > and this is the only location where sqlservr.exe is found on the machine.
> >
> >
> > "Tibor Karaszi" wrote:
> >
> > > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> > > server?
> > >
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > http://www.karaszi.com/sqlserver/default.asp
> > > http://www.solidqualitylearning.com/
> > >
> > >
> > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > > Hi
> > > > I have written an extended stored procedure DLL, thanks to the people who
> > > > helped me on this.
> > > > however i wonder if anyone could shed any light on my deployment issues that
> > > > I'm having with it.
> > > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > > this PC's local default instance of MSDE without problems. It uses no managed
> > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > > ODBC: Msg 0, Level 16, State 1
> > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > > 126(error not found).
> > > >
> > > > The only thing I can think to be different is that one's got Win2000,
> > > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > > >
> > > > I checked that the names are the correct case, correct names of the
> > > > procedure and the DLL filename and everything.
> > > >
> > > > What could be wrong?
> > > >
> > > > Thanks
> > > >
> > >
> > >
> > >
>
>|||Possibly some stuff is linked in by the compiling environment. I haven't used C or C++ for some 12
years now, so this is only a guess...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bonj" <Bonj@.discussions.microsoft.com> wrote in message
news:67E3A9A6-3BC7-4110-9188-8FC3996555A8@.microsoft.com...
> Like I say, it does it the same with a 'blank' extended stored procedure...
> i.e. just let the wizard create one, don't add any code, and compile. That
> doesn't work on it either.
>
> "Tibor Karaszi" wrote:
> > I see, it was only a wild guess...
> >
> > Re-reading the error message, it can also be that the DLL you produced in return references some
> > other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
> > here... :-\).
> >
> > I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
> > problem might be. Perhaps some of the VC persons can pick up on that. ;-)
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> > > Nope. Like I say, the following is true of both dev machine, and deployment
> > > target:
> > > There's only one, default, instance of SQL Server (MSDE) on the machine. The
> > > path of the binaries is
> > > c:\program files\microsoft sql server\mssql\binn
> > > and this is the only location where sqlservr.exe is found on the machine.
> > >
> > >
> > > "Tibor Karaszi" wrote:
> > >
> > > > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of
SQL
> > > > server?
> > > >
> > > > --
> > > > Tibor Karaszi, SQL Server MVP
> > > > http://www.karaszi.com/sqlserver/default.asp
> > > > http://www.solidqualitylearning.com/
> > > >
> > > >
> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > > > Hi
> > > > > I have written an extended stored procedure DLL, thanks to the people who
> > > > > helped me on this.
> > > > > however i wonder if anyone could shed any light on my deployment issues that
> > > > > I'm having with it.
> > > > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > > > this PC's local default instance of MSDE without problems. It uses no managed
> > > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > > > ODBC: Msg 0, Level 16, State 1
> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > > > 126(error not found).
> > > > >
> > > > > The only thing I can think to be different is that one's got Win2000,
> > > > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > > > >
> > > > > I checked that the names are the correct case, correct names of the
> > > > > procedure and the DLL filename and everything.
> > > > >
> > > > > What could be wrong?
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >|||As you suggested I created a default extended stored procedure using
VS.NET'03 on WinXP...I used the depends.exe to determine the dependencies.
Depends.exe reported and error trying to find the OPENDS60.DLL. Perhaps this
is part of your problem...
"Bonj" wrote:
> Like I say, it does it the same with a 'blank' extended stored procedure...
> i.e. just let the wizard create one, don't add any code, and compile. That
> doesn't work on it either.
>
> "Tibor Karaszi" wrote:
> > I see, it was only a wild guess...
> >
> > Re-reading the error message, it can also be that the DLL you produced in return references some
> > other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
> > here... :-\).
> >
> > I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
> > problem might be. Perhaps some of the VC persons can pick up on that. ;-)
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> > > Nope. Like I say, the following is true of both dev machine, and deployment
> > > target:
> > > There's only one, default, instance of SQL Server (MSDE) on the machine. The
> > > path of the binaries is
> > > c:\program files\microsoft sql server\mssql\binn
> > > and this is the only location where sqlservr.exe is found on the machine.
> > >
> > >
> > > "Tibor Karaszi" wrote:
> > >
> > > > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> > > > server?
> > > >
> > > > --
> > > > Tibor Karaszi, SQL Server MVP
> > > > http://www.karaszi.com/sqlserver/default.asp
> > > > http://www.solidqualitylearning.com/
> > > >
> > > >
> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > > > Hi
> > > > > I have written an extended stored procedure DLL, thanks to the people who
> > > > > helped me on this.
> > > > > however i wonder if anyone could shed any light on my deployment issues that
> > > > > I'm having with it.
> > > > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > > > this PC's local default instance of MSDE without problems. It uses no managed
> > > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > > > ODBC: Msg 0, Level 16, State 1
> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > > > 126(error not found).
> > > > >
> > > > > The only thing I can think to be different is that one's got Win2000,
> > > > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > > > >
> > > > > I checked that the names are the correct case, correct names of the
> > > > > procedure and the DLL filename and everything.
> > > > >
> > > > > What could be wrong?
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >|||oh right... i'll check it out when I get back to work..
Cheers for the investigation, appreciate it!
"Mike M" <Mike M@.discussions.microsoft.com> wrote in message
news:D91F9749-AED1-44C0-9AA0-6251A39EE6B2@.microsoft.com...
> As you suggested I created a default extended stored procedure using
> VS.NET'03 on WinXP...I used the depends.exe to determine the dependencies.
> Depends.exe reported and error trying to find the OPENDS60.DLL. Perhaps
> this
> is part of your problem...
> "Bonj" wrote:
>> Like I say, it does it the same with a 'blank' extended stored
>> procedure...
>> i.e. just let the wizard create one, don't add any code, and compile.
>> That
>> doesn't work on it either.
>>
>> "Tibor Karaszi" wrote:
>> > I see, it was only a wild guess...
>> >
>> > Re-reading the error message, it can also be that the DLL you produced
>> > in return references some
>> > other DLL file, and this is the file that cannot be found. (I'm sorry
>> > if I'm stating the obvious
>> > here... :-\).
>> >
>> > I'm sure that there are tools out there to check DLL dependencies etc
>> > to investigate what the
>> > problem might be. Perhaps some of the VC persons can pick up on that.
>> > ;-)
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
>> > > Nope. Like I say, the following is true of both dev machine, and
>> > > deployment
>> > > target:
>> > > There's only one, default, instance of SQL Server (MSDE) on the
>> > > machine. The
>> > > path of the binaries is
>> > > c:\program files\microsoft sql server\mssql\binn
>> > > and this is the only location where sqlservr.exe is found on the
>> > > machine.
>> > >
>> > >
>> > > "Tibor Karaszi" wrote:
>> > >
>> > > > Sorry for the obvious question, but perhaps you added the dll file
>> > > > for the wrong instance of SQL
>> > > > server?
>> > > >
>> > > > --
>> > > > Tibor Karaszi, SQL Server MVP
>> > > > http://www.karaszi.com/sqlserver/default.asp
>> > > > http://www.solidqualitylearning.com/
>> > > >
>> > > >
>> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
>> > > > > Hi
>> > > > > I have written an extended stored procedure DLL, thanks to the
>> > > > > people who
>> > > > > helped me on this.
>> > > > > however i wonder if anyone could shed any light on my deployment
>> > > > > issues that
>> > > > > I'm having with it.
>> > > > > Basically, I built it on my XP development PC with VC7.1. I can
>> > > > > deploy it on
>> > > > > this PC's local default instance of MSDE without problems. It
>> > > > > uses no managed
>> > > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
>> > > > > I am trying to deploy it to a different PC with Win2K, and
>> > > > > again - a local,
>> > > > > default, instance of MSDE. I copied it to C:\program
>> > > > > files\microsoft sql
>> > > > > server\mssql\binn just as on my pc, added it using
>> > > > > "sp_addextendedproc
>> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
>> > > > > ODBC: Msg 0, Level 16, State 1
>> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it
>> > > > > references. Reason:
>> > > > > 126(error not found).
>> > > > >
>> > > > > The only thing I can think to be different is that one's got
>> > > > > Win2000,
>> > > > > whereas my dev. PC has got XP. This shouldn't matter though,
>> > > > > should it?
>> > > > >
>> > > > > I checked that the names are the correct case, correct names of
>> > > > > the
>> > > > > procedure and the DLL filename and everything.
>> > > > >
>> > > > > What could be wrong?
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > >
>> > > >
>> > > >
>> >
>> >
>> >|||I ran depends.exe on it and it said this at the bottom in red:
Warning: At least one module has an unresolved import due to a missing
export function in a delay-load dependent module.
How can I find which one, and resolve it?|||It didn't seem to be the opends60.dll, because the target machine has got it
in its SQL server "binn" directory.
"Bonj" <benjtaylor at hotpop d0t com> wrote in message
news:uXSnkr5tEHA.2072@.tk2msftngp13.phx.gbl...
> oh right... i'll check it out when I get back to work..
> Cheers for the investigation, appreciate it!
> "Mike M" <Mike M@.discussions.microsoft.com> wrote in message
> news:D91F9749-AED1-44C0-9AA0-6251A39EE6B2@.microsoft.com...
>> As you suggested I created a default extended stored procedure using
>> VS.NET'03 on WinXP...I used the depends.exe to determine the
>> dependencies.
>> Depends.exe reported and error trying to find the OPENDS60.DLL. Perhaps
>> this
>> is part of your problem...
>> "Bonj" wrote:
>> Like I say, it does it the same with a 'blank' extended stored
>> procedure...
>> i.e. just let the wizard create one, don't add any code, and compile.
>> That
>> doesn't work on it either.
>>
>> "Tibor Karaszi" wrote:
>> > I see, it was only a wild guess...
>> >
>> > Re-reading the error message, it can also be that the DLL you produced
>> > in return references some
>> > other DLL file, and this is the file that cannot be found. (I'm sorry
>> > if I'm stating the obvious
>> > here... :-\).
>> >
>> > I'm sure that there are tools out there to check DLL dependencies etc
>> > to investigate what the
>> > problem might be. Perhaps some of the VC persons can pick up on that.
>> > ;-)
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
>> > > Nope. Like I say, the following is true of both dev machine, and
>> > > deployment
>> > > target:
>> > > There's only one, default, instance of SQL Server (MSDE) on the
>> > > machine. The
>> > > path of the binaries is
>> > > c:\program files\microsoft sql server\mssql\binn
>> > > and this is the only location where sqlservr.exe is found on the
>> > > machine.
>> > >
>> > >
>> > > "Tibor Karaszi" wrote:
>> > >
>> > > > Sorry for the obvious question, but perhaps you added the dll file
>> > > > for the wrong instance of SQL
>> > > > server?
>> > > >
>> > > > --
>> > > > Tibor Karaszi, SQL Server MVP
>> > > > http://www.karaszi.com/sqlserver/default.asp
>> > > > http://www.solidqualitylearning.com/
>> > > >
>> > > >
>> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
>> > > > > Hi
>> > > > > I have written an extended stored procedure DLL, thanks to the
>> > > > > people who
>> > > > > helped me on this.
>> > > > > however i wonder if anyone could shed any light on my deployment
>> > > > > issues that
>> > > > > I'm having with it.
>> > > > > Basically, I built it on my XP development PC with VC7.1. I can
>> > > > > deploy it on
>> > > > > this PC's local default instance of MSDE without problems. It
>> > > > > uses no managed
>> > > > > code whatsoever, and is compiled without /clr. Totally
>> > > > > unmanaged.
>> > > > > I am trying to deploy it to a different PC with Win2K, and
>> > > > > again - a local,
>> > > > > default, instance of MSDE. I copied it to C:\program
>> > > > > files\microsoft sql
>> > > > > server\mssql\binn just as on my pc, added it using
>> > > > > "sp_addextendedproc
>> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
>> > > > > ODBC: Msg 0, Level 16, State 1
>> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it
>> > > > > references. Reason:
>> > > > > 126(error not found).
>> > > > >
>> > > > > The only thing I can think to be different is that one's got
>> > > > > Win2000,
>> > > > > whereas my dev. PC has got XP. This shouldn't matter though,
>> > > > > should it?
>> > > > >
>> > > > > I checked that the names are the correct case, correct names of
>> > > > > the
>> > > > > procedure and the DLL filename and everything.
>> > > > >
>> > > > > What could be wrong?
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > >
>> > > >
>> > > >
>> >
>> >
>> >
>