odbc timeout

Hi Ralf
I am not sure why you need to create a new ODBC connection if this
previously existed? If this did not previously exist then you can not say fo
r
certain it is the NIC that is causing this, therefore check to see if you ca
n
ping the server and/or connect via osql, check that the firewall is not
blocking any port being used. Other things to look out for would be faulty
cabling, a problem with a hub or switch, out-of-date drivers.
John
"Ralf Temme" wrote:

> Hallo,
> we have to installed a new nic on a w2k-server with sql-server2000. The
> proberties TCP/IP are the same like on the old nic. SQL-Connection are oka
y,
> but not the odbc-connection! During the configuratin of the odbc-connectio
n
> on the client we recieve an timeout error. 1.-3. or 4. try are succesful.
But
> than timeout. Nameresolution seems okay. We have no error massage or id. O
nly
> timeout, connection failed!
> What′s the reason for this? Only a new network-card!
> Thanks for help!Hallo,
we have to installed a new nic on a w2k-server with sql-server2000. The
proberties TCP/IP are the same like on the old nic. SQL-Connection are okay,
but not the odbc-connection! During the configuratin of the odbc-connection
on the client we recieve an timeout error. 1.-3. or 4. try are succesful. Bu
t
than timeout. Nameresolution seems okay. We have no error massage or id. Onl
y
timeout, connection failed!
What′s the reason for this? Only a new network-card!
Thanks for help!|||Hi Ralf
I am not sure why you need to create a new ODBC connection if this
previously existed? If this did not previously exist then you can not say fo
r
certain it is the NIC that is causing this, therefore check to see if you ca
n
ping the server and/or connect via osql, check that the firewall is not
blocking any port being used. Other things to look out for would be faulty
cabling, a problem with a hub or switch, out-of-date drivers.
John
"Ralf Temme" wrote:

> Hallo,
> we have to installed a new nic on a w2k-server with sql-server2000. The
> proberties TCP/IP are the same like on the old nic. SQL-Connection are oka
y,
> but not the odbc-connection! During the configuratin of the odbc-connectio
n
> on the client we recieve an timeout error. 1.-3. or 4. try are succesful.
But
> than timeout. Nameresolution seems okay. We have no error massage or id. O
nly
> timeout, connection failed!
> What′s the reason for this? Only a new network-card!
> Thanks for help!|||Hi John,
we create a new odbc connection only for testing. The error is the same like
the old one. We have applications as sql-clients, works normaly. So I′m sur
e
network connection is okay. One application needs the odbc connection. These
one failed with timeout error. Try to connect passed 3-4 times, than
timeout. After a few seconds I can start again: the same (passed 3-4 times,
than timeout). ODBCPING passed. Ping passed. Firewall is not activ. MDAC is
new. SP4 for SQL-Server is installed. Driver for the NIC (Intel) is the new.
It seems like an limit of odbc-requests, but I don′t know!
"John Bell" schrieb:
[vbcol=seagreen]
> Hi Ralf
> I am not sure why you need to create a new ODBC connection if this
> previously existed? If this did not previously exist then you can not say
for
> certain it is the NIC that is causing this, therefore check to see if you
can
> ping the server and/or connect via osql, check that the firewall is not
> blocking any port being used. Other things to look out for would be faulty
> cabling, a problem with a hub or switch, out-of-date drivers.
> John
> "Ralf Temme" wrote:
>|||Hi Ralf
If there is a limit on your connections then I would expect other systems to
experience problems as well! You could set ODBC tracing on, but I am not sur
e
that it will tell you anything extra. You may also want to try a different
NIC that you know is working. You may also want to try plugging the maching
into the same hub/switch as the server using different cables.
John
"Ralf Temme" wrote:
[vbcol=seagreen]
> Hi John,
> we create a new odbc connection only for testing. The error is the same li
ke
> the old one. We have applications as sql-clients, works normaly. So I′m s
ure
> network connection is okay. One application needs the odbc connection. The
se
> one failed with timeout error. Try to connect passed 3-4 times, than
> timeout. After a few seconds I can start again: the same (passed 3-4 times
,
> than timeout). ODBCPING passed. Ping passed. Firewall is not activ. MDAC i
s
> new. SP4 for SQL-Server is installed. Driver for the NIC (Intel) is the ne
w.
> It seems like an limit of odbc-requests, but I don′t know!
> "John Bell" schrieb:
>|||You say that one app is having problems. What is the MDAC for the app softwa
re?
Is the app using 'generic' odbc or is it writing to the API?
Also, during the set up of the ODBC driver in ODBC Administrator,t here is a
'test connection' option. When you do that test does it fail?
"John Bell" wrote:
[vbcol=seagreen]
> Hi Ralf
> If there is a limit on your connections then I would expect other systems
to
> experience problems as well! You could set ODBC tracing on, but I am not s
ure
> that it will tell you anything extra. You may also want to try a different
> NIC that you know is working. You may also want to try plugging the machin
g
> into the same hub/switch as the server using different cables.
> John
>
> "Ralf Temme" wrote:
>|||Hi John,
we create a new odbc connection only for testing. The error is the same like
the old one. We have applications as sql-clients, works normaly. So I′m sur
e
network connection is okay. One application needs the odbc connection. These
one failed with timeout error. Try to connect passed 3-4 times, than
timeout. After a few seconds I can start again: the same (passed 3-4 times,
than timeout). ODBCPING passed. Ping passed. Firewall is not activ. MDAC is
new. SP4 for SQL-Server is installed. Driver for the NIC (Intel) is the new.
It seems like an limit of odbc-requests, but I don′t know!
"John Bell" schrieb:
[vbcol=seagreen]
> Hi Ralf
> I am not sure why you need to create a new ODBC connection if this
> previously existed? If this did not previously exist then you can not say
for
> certain it is the NIC that is causing this, therefore check to see if you
can
> ping the server and/or connect via osql, check that the firewall is not
> blocking any port being used. Other things to look out for would be faulty
> cabling, a problem with a hub or switch, out-of-date drivers.
> John
> "Ralf Temme" wrote:
>|||Hi Ralf
If there is a limit on your connections then I would expect other systems to
experience problems as well! You could set ODBC tracing on, but I am not sur
e
that it will tell you anything extra. You may also want to try a different
NIC that you know is working. You may also want to try plugging the maching
into the same hub/switch as the server using different cables.
John
"Ralf Temme" wrote:
[vbcol=seagreen]
> Hi John,
> we create a new odbc connection only for testing. The error is the same li
ke
> the old one. We have applications as sql-clients, works normaly. So I′m s
ure
> network connection is okay. One application needs the odbc connection. The
se
> one failed with timeout error. Try to connect passed 3-4 times, than
> timeout. After a few seconds I can start again: the same (passed 3-4 times
,
> than timeout). ODBCPING passed. Ping passed. Firewall is not activ. MDAC i
s
> new. SP4 for SQL-Server is installed. Driver for the NIC (Intel) is the ne
w.
> It seems like an limit of odbc-requests, but I don′t know!
> "John Bell" schrieb:
>|||You say that one app is having problems. What is the MDAC for the app softwa
re?
Is the app using 'generic' odbc or is it writing to the API?
Also, during the set up of the ODBC driver in ODBC Administrator,t here is a
'test connection' option. When you do that test does it fail?
"John Bell" wrote:
[vbcol=seagreen]
> Hi Ralf
> If there is a limit on your connections then I would expect other systems
to
> experience problems as well! You could set ODBC tracing on, but I am not s
ure
> that it will tell you anything extra. You may also want to try a different
> NIC that you know is working. You may also want to try plugging the machin
g
> into the same hub/switch as the server using different cables.
> John
>
> "Ralf Temme" wrote:
>