Very strange behavior of SQLServer with connection from CGI

[mdurliSPAMFILTER]

Hello,
I developed a win32 .exe CGI that connects to a clustered SQLServer to
report some data.
The software is written with Borland C++Builder.
This is the oledb string:
Name=Provider=SQLOLEDB;Password=xxx;Persist Security Info=True;User
ID=xxxx;Data Source=xxxxx;Initial Catalog=xxxxx;Network
Library=dbmssocn

It suddendly stopped working on my customer network, so I made some
test and I verivied that the problem is on the connection with
SQLServer: my test program just opens a connection, closes it and
exits, reporting in a log file if the open was successful or failed.

If I run the program locally, just launching it, no problem, it works.
I can run it mutilple time continuosly and is connects every time.

If I run the program through my webserver, as a CGI that's how it is
supposed to work (http:\\localhost\scripts\connect.exe), it connects
the first time, and then I have to wait 40 seconds to connect again
successfully, or it fails.

If I try against MY sqlserver on my laptop or on my network no 40 sec
problems, but on my customer network, with THEIR SQLServer , if I try
to connect from their webserver, or from my laptop webserver, I have
this 40sec problem.

I analyzed the network traffic, and I discovered that when I run my
test program locally it originates only TCP/IP packets, and SQLServer
answers only with TCP/IP.
But when I use it from the webserver as a CGI, it originates an UDP
packet, then SQL answers with another UDP packet, and then they
communicate over TCP/IP.
This when it works: the second time my program continues to send the
UDP packet, but it receives no answer, and fails the communication.

I can only say that:
- we haven't touched the program for months, and it really stopped
working suddendly, so I suspect that something in my customer netowrk
has changed
- I tried many different OLEDB strings, disabling connection pooling
and all the services, calling the SQLServer by name or IP...
- the problem can't be related to my program, because now is really
just an oledb connection test

Anyone have an idea?

Thank you very much,
Mattia

[Geoff N. Hiten]

First guess, this is not a default SQL instance. I think your customer
network has disabled UDP as a "security" measure. SQL clients use a UDP
connection to port 1434 to resolve port numbers for named instances. If
your customer won't allow UPD, you can modify the connection information to
include the port number of the named instance or create a client alias that
specifies a port number. You can use the SQL Server Network utility to lock
an instance to a port number.

Finally, don't cross-post to the universe.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com

I support the Professional Association for SQL Server
www.sqlpass.org

<md**************@hotmail.com> wrote in message
news:ju********************************@4ax.com...

Hello,
I developed a win32 .exe CGI that connects to a clustered SQLServer to
report some data.
The software is written with Borland C++Builder.
This is the oledb string:
Name=Provider=SQLOLEDB;Password=xxx;Persist Security Info=True;User
ID=xxxx;Data Source=xxxxx;Initial Catalog=xxxxx;Network
Library=dbmssocn

It suddendly stopped working on my customer network, so I made some
test and I verivied that the problem is on the connection with
SQLServer: my test program just opens a connection, closes it and
exits, reporting in a log file if the open was successful or failed.

If I run the program locally, just launching it, no problem, it works.
I can run it mutilple time continuosly and is connects every time.

If I run the program through my webserver, as a CGI that's how it is
supposed to work (http:\\localhost\scripts\connect.exe), it connects
the first time, and then I have to wait 40 seconds to connect again
successfully, or it fails.

If I try against MY sqlserver on my laptop or on my network no 40 sec
problems, but on my customer network, with THEIR SQLServer , if I try
to connect from their webserver, or from my laptop webserver, I have
this 40sec problem.

I analyzed the network traffic, and I discovered that when I run my
test program locally it originates only TCP/IP packets, and SQLServer
answers only with TCP/IP.
But when I use it from the webserver as a CGI, it originates an UDP
packet, then SQL answers with another UDP packet, and then they
communicate over TCP/IP.
This when it works: the second time my program continues to send the
UDP packet, but it receives no answer, and fails the communication.

I can only say that:
- we haven't touched the program for months, and it really stopped
working suddendly, so I suspect that something in my customer netowrk
has changed
- I tried many different OLEDB strings, disabling connection pooling
and all the services, calling the SQLServer by name or IP...
- the problem can't be related to my program, because now is really
just an oledb connection test

Anyone have an idea?

Thank you very much,
Mattia