扩展存储过程 [英] Extended stored procedure

问题描述

你好


我有一个问题，我已经有几个月了，我不能得到

*任何*延长存储过程在PC上运行，而不是我开发的那个。

我测试的那些都有完全相同的SQL服务器

配置（默认安装MSDE）。 " sp_addextendedproc"似乎没有错误运行
，但是在调用xp时，我收到错误：

无法加载DLL testproc.dll或它引用的DLL之一。原因：

126（找不到错误）。


之前我已经发布过这个效果了，我得到的所有建议都是检查所有

依赖项安装在目标计算机上。这有助于提醒你，但现在我已经检查过它们都是。即使我没有为项目添加任何代码，它仍然会给出错误

- 只需使用向导为您提供的骨架

构建它。


有没有一个有SQL服务器的人可能会给它一个测试，看看他们能不能做什么？b $ b我想做什么？我正在努力做的事情真的非常简单......我必须强调，这个部署的噩梦*仍然只发生在

向导生成的骨架上...而不是Windows 2000而不是

XP，目标机器与开发机器相同（好吧，

他们显然不是，但是根据我的理解，他们是。）它只是在确定它们与众不同的任何想法 -


我确定它只是一些DLL我没有考虑到，但我不能认为

是什么。

opends60.dll和所有标准的运行时库，如msvcrt.dll等。

都在那里。

解决方案

你能为dll创建一个安装包吗？可能是你最好的选择。


杰夫


" Bonj" <博** @ discussions.microsoft.com>在消息中写道

news：8B ********************************** @ microsof t.com ...

你好

我有一个问题，我已经有几个月了，我不能得到
*任何*扩展存储过程在PC上运行，而不是我开发的那个。
我测试的那些都具有完全相同的SQL服务器配置（默认安装MSDE） ）。 " sp_addextendedproc"出现
运行没有错误，但在调用xp时，我收到错误：
无法加载DLL testproc.dll，或它引用的DLL之一。
原因：126（找不到错误）。

之前我已发布此效果，我建议的是检查所有
目标上安装的依赖项机。这有助于被提醒，但现在我已经检查过它们都是。即使我没有在项目中添加任何代码，它仍然会产生
错误 - 只需使用向导为您提供的
骨架构建它。

有人可以SQL服务器可能会给它一个测试，看看他们是否可以做我想做的事情？我正在努力做的事情真的非常简单......我必须强调，这个部署噩梦*仍然只发生在
向导生成的骨架......而不是窗户2000而不是
到XP，目标机器与开发机器相同（好吧，
他们显然不是，但根据我的理解他们是。）。它只是
确定它们的不同之处 - 任何想法？

我确定它只是一些我还没有考虑到的DLL，但是我不能想是什么。
opends60.dll和所有标准的运行时库，如msvcrt.dll
等都在那里。

mmmm ...也许，我会试一试。

DLL必须安装到SQL服务器的binn目录中 - 尽管如此/>
你知道是否有自动方式吗？

可能没有，我只需要硬编码

％programfiles％\ microsros sql server \mssql \ binn"作为安装路径......或者

是否可以安装到不同的路径？

我在DLL上做了dumpbin / dependents，它给了我三个依赖项：

kernel32.dll（很明显），opends60.dll（db库）和msvcr71d.dll。

嗯......当然是VC运行时 - 但是那个安装在目标

机器上？不，msvcr71d.dll不是它的调试版本，所以我做了一个

发布版本然后dumpbin确认它现在依赖于msvcr71.dll

代替，* *安装在目标机器上（在.NET框架的

目录中） - 但仍然无济于事！我以为我已经解决了，但没有。它不会是
！


但是我们非常感谢任何进一步的想法！


" Jeff Dillon" < JE ** @ removeemergencyreporting.com>在消息中写道

news：e6 ************** @ TK2MSFTNGP09.phx.gbl ...

你能创建一个设置吗？包的dll？可能是你最好的选择。

杰夫

Bonj <博** @ discussions.microsoft.com>在消息中写道
新闻：8B ********************************** @ microsof t.com。 ..

你好

我有一个问题，我已经有好几个月，我不能得到
*任何*扩展存储过程在PC上运行，而不是我开发的那个。
我测试的那些都具有完全相同的SQL服务器配置（默认安装MSDE） ）。 sp_addextendedproc
出现

到

运行没有错误，但在调用xp时，我收到错误：
无法加载DLL testproc .dll，或它引用的一个DLL。

原因：

126（找不到错误）。

我已发布到之前的这个效果，我建议的是检查所有

依赖关系安装在目标机器上。这有助于被提醒，但现在我已经检查过它们都是。它仍然提供

错误

即使我没有向项目中添加任何代码 - 只需使用

骨架<向导给你的blockquote class =post_quotes>。

有没有SQL服务器的人可能会给它一个测试，看看他们是否可以

做

我想做什么？我正在努力做的事情真的非常简单......
我必须强调，这个部署的噩梦*仍然只发生在
向导生成的骨架上......除了Windows 2000而不是

到

XP，目标机器与开发机器相同（好吧，
它们显然不是，但是根据我的理解，他们是。）它只是

钉住

了解它们是如何不同的 - 任何想法？

我确定它是'只是一些DLL我没有考虑到，但我不能

想想

什么。
opends60.dll和所有标准的运行时库例如msvcrt.dll

等。

都在那里。

也许你会尝试一下？为什么要寻找其他想法呢？


创建一个安装包，并安装它。


然后将dll移动到binn目录，并运行regsvr32


杰夫


" Bonj" < benjtaylor at hotpop d0t com>在消息中写道

新闻：#A ************** @ TK2MSFTNGP09.phx.gbl ...

mmmm ...也许，我会试试。
DLL必须安装到SQL服务器的binn目录中 -
你知道是否有自动方式吗？
可能没有，我只需要硬编码
"％programfiles％\ microsros sql server \mssql \ binn"作为安装路径...或
是否可以安装到不同的路径？
我在DLL上做了dumpbin / dependents，它给了我三个依赖：
kernel32.dll（显然），opends60.dll（db库）和msvcr71d.dll。
嗯... VC运行时，当然 - 但是安装在目标机器上？不，msvcr71d.dll不是它的调试版本，所以我做了一个
发布版本然后dumpbin确认它现在依赖于
msvcr71.dll而不是* *安装在目标机器上（在.NET框架的
目录中） - 但仍无济于事！我以为我已经解决了，但没有。
不是这样！

任何进一步的想法都非常受欢迎！

Jeff Dillon < JE ** @ removeemergencyreporting.com>在消息中写道
新闻：e6 ************** @ TK2MSFTNGP09.phx.gbl ...

你能为dll创建一个安装包吗？ ？可能是你最好的选择。

杰夫

Bonj <博** @ discussions.microsoft.com>在消息中写道
新闻：8B ********************************** @ microsof t.com。 ..

你好

我有一个问题，我已经有好几个月，我不能得到
*任何*扩展存储过程在PC上运行，而不是我开发的那个。
我测试的那些都具有完全相同的SQL服务器配置（默认安装MSDE） ）。 sp_addextendedproc
出现

到

运行没有错误，但在调用xp时，我收到错误：
无法加载DLL testproc .dll，或它引用的一个DLL。

原因：

126（找不到错误）。

我已发布到这个效果之前，我建议的是检查
所有

依赖关系安装在目标机器上。这有助于

被提醒，但现在我已经检查过它们都是。它仍然提供

错误

即使我没有向项目中添加任何代码 - 只需使用

骨架<向导给你的blockquote class =post_quotes>。

有没有SQL服务器的人可能会给它一个测试，看看他们是否
可以做

什么我想做什么？我正在努力

确实非常简单...我必须强调，这个部署的噩梦*仍然只发生在
向导生成的骨架上...而不是windows 2000为

反对

XP，目标机器与开发相同机器（好吧，
他们显然不是，但根据我的理解他们是。）。它只是

钉住

了解它们是如何不同的 - 任何想法？

我确定它是'只是一些DLL我没有考虑到，但我不能

想想

什么。
opends60.dll和所有标准的运行时库例如msvcrt.dll

等。

都在那里。

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.

解决方案

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.

这篇关于扩展存储过程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！