Extended Stored Procedure problem

Hi,
I made some extended strored procedures
and they goes well when they are placed at
c:\windows\system32 or the same derectory to
sqlservr.exe which is usualy in C:\Program Files\
Microsoft SQL Server\MSSQL\Binn.

I thought it's OK wherever they are placed
as long as I put them to the system path.

But actually they didn't work at all
when they were placed to the other path
that I had newly added as a system path.

Here is the contents of 'path' valiable:

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\Sy stem32\Wbem;C:\WINDOWS\System32\AmiClick;C:\Progra m Files\Microsoft SQL Server\80\Tools\BINN:C:\Program Files/INC

I just added only "C:\Program Files/INC",
placed the extended stored procedures there,
then called them through a trigger.

Can Somebody tell me what was wrong?
Please help me if you have any informations about this issue.

regards,
Takanobu MaekawaKeep in mind that the forward slash causes all kinds of problems in the NT environment. I would very strongly recommend that you change it to a backslash, which is the NT default path element separator.

-PatP|||Thanks.

I've fixed it now as you said and tried again,
but the problem remains. mm..why??|||Have you enabled the path on SQL server and from where you;re calling this XP.|||Thanks for reply, but I couldn't understand what you meant ...

I just want to put the Extended SPs into the place except system32
or bin directory of SQL Server or the other system directory,
and then run them from the remote hosts.

well,So far,I wonder the problem might be that
the SQL Server uses local system account.(I don't want to change it)

I guess every thing would be OK if I can put the path which I want to add to the local system account's path...but how??
Isn't the system path shared with the local system acount's one?
I'm very confused.

Is there some one who had a problem like me and solved it?
If you know any informations about this issue,please tell me too.

regards.|||ENsure the path is set on the server not on the local client machine.|||Originally posted by Satya
ENsure the path is set on the server not on the local client machine.

Yes, I'm sure that the path is set on the server's system path, not the client's one ...|||Can you post the error generated while working with this XP.|||well, here is the result of running one of XPs
through the Query Analyzer.

----------------------
<R_DB_T_KANJA>Jn 03 17 2004 10:36AM
R_MQ_T_BEDKANJALINK Jn 17 03 2004 10:36:27:390
R_MQ_T_BEDKANJALINK I 17 03 2004 10:36:27:390
R_MQ_T_BEDKANJALINK Jn 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK I 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK Jn 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK I 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK Jn 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK I 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK Jn 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK I 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK Jn 17 03 2004 10:36:27:403
R_MQ_T_BEDKANJALINK I 17 03 2004 10:36:27:403
<R_DB_T_KANJA>I 03 17 2004 10:36AM
<R_DB_T_KANJA2>I 03 17 2004 10:36AM
R_MQ_T_KANJA<UPDATE> Jn 17 03 2004 10:36:27:967
ODBC: bZ[W 0Ax 16A 1
DLL INC_MNSQL.dll [h??AQ?? DLL 1 ?[h??BR : 126(w肳?W[??B)B

R_MQ_T_KANJA<UPDATE> @.lSeqNum=1 @.nByotoCode=21
R_MQ_T_KANJA<UPDATE> (?ID 1005)XV?B @.Old_bytSex=1 @.New_bytSex =0 (NULL -> 0)

(1 ?)
R_MQ_T_KANJA<UPDATE> I 17 03 2004 10:36:28:060
------------------------

As you see, the localization of SQL Server is set to Japanese.
Should I translate the messages into English?

'R_DB_ ...' are output of print function in triggers.
XP is called from them.
The DLL the XP is written is INC_MNSQL.dll.
The error said the DLL can not be loaded.|||Based upon the last link of your reply, I feel this KBA http://support.microsoft.com/default.aspx?scid=kb;en-us;Q151596 may be suitable to resolve.

HTH|||Can you put the XP DLL into the SQL binary directory (by default, C:\Program Files\Microsoft SQL Server\Mssql\Binn although that can be changed at installation time) and have them work correctly? Did you by any chance specify a pathname when you called sp_addextendedproc (which is a bad thing)?

-PatP|||Finally, I've solved this problem.
I don't know this is the essential solution for this problem,
but today, once I rebooted the Server machine
(it's been long time --at least 2 months since I rebooted the server machine last time),then the system path which I added began to work well !!