External stored procedures and sockets

I hope this is the right group for this question.
I am trying to deliver a UDP multicast data stream as a notification method
using an extended stored procedure. The multicast message, however, is not
making it out on the network. (At least not in a form that I can recognize.
)
- I can make the multicast work from a stand-alone console application using
the same procedure with dummy data, so I think I'm setting up the multicast
properly.
- I have verified that the extended stored procedure receives the parameters
from the trigger that calls it successfully, so the external stored procedur
e
is being called properly.
- I have verified that there are no error returns from any of the socket (or
other) API calls in the extended stored procedure, so the procedure thinks
it's doing what it ought to.
My conclusion is that there is something in the execution environment that
is keeping the extended stored procedure from working as expected (i.e., as
it does as a simple subroutine in the console application). On the other
hand, I know I've seen people write about using sockets in their extended
stored procedures.
Any ideas as to what I'm doing wrong?
Thanks.
Ed Hoch
--
GEDDS Manager
Geophysical Institute
University of Alaska FairbanksHi
Have you checked that there is not a firewall blocking this port? Also make
sure that your account has the correct access to do this.
John
"Edward Hoch" wrote:

> I hope this is the right group for this question.
> I am trying to deliver a UDP multicast data stream as a notification metho
d
> using an extended stored procedure. The multicast message, however, is no
t
> making it out on the network. (At least not in a form that I can recogniz
e.)
> - I can make the multicast work from a stand-alone console application usi
ng
> the same procedure with dummy data, so I think I'm setting up the multicas
t
> properly.
> - I have verified that the extended stored procedure receives the paramete
rs
> from the trigger that calls it successfully, so the external stored proced
ure
> is being called properly.
> - I have verified that there are no error returns from any of the socket (
or
> other) API calls in the extended stored procedure, so the procedure thinks
> it's doing what it ought to.
> My conclusion is that there is something in the execution environment that
> is keeping the extended stored procedure from working as expected (i.e., a
s
> it does as a simple subroutine in the console application). On the other
> hand, I know I've seen people write about using sockets in their extended
> stored procedures.
> Any ideas as to what I'm doing wrong?
> Thanks.
> Ed Hoch
> --
> GEDDS Manager
> Geophysical Institute
> University of Alaska Fairbanks|||Hi John,
I am assuming that since I can run the same code successfully from a console
application, that it is not a firewall issue. I don't think it's possible t
o
"firewall" a specific process (like SQL Server), is it? Also, I have logged
in to the console as the user that SQL Server runs under. The console
application still works. So, unless SQL Server is somehow managinig to
affect the permissions of that account, I don't think it's an access
problem, either.
Feel free to correct me if any of my assumptions are wrong. Thanks very
much for your response.
Ed
"John Bell" wrote:
> Hi
> Have you checked that there is not a firewall blocking this port? Also mak
e
> sure that your account has the correct access to do this.
> John
> "Edward Hoch" wrote:
>