However, we are having problems with IIS6.0 and Windows 2003 Server when connecting to a second Windows 2003 Server running SQL 2000 Server. IIS6.0 and SQL on the same server works fine.
We see intermittent connection problems resulting in:
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
We have tried everything we have found trawling the web and still have no idea what is causing it.
One ASP script in particular that simply updates a table, fails most of the time but does VERY rarely run successfully. The same script NEVER failed under NT/SQL7.0 or W2K/SQL2000.
We have increased timeout settings in IIS and the ASP scripts themselves. We have changed the OLEDB connection to reference the SQL Server IP address instead of its name but nothing tried has made any difference.
Any suggestions would be gratefully received!
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.SqlJunkies.com/newsgroups Our newsgroup engine supports Post Alerts, Ratings, and Searching.
That error message is too generic to give specific information as to why it
is failing.
Have you checked for locking /blocking on the server?
You state that the ASP page is performing an update.
Otherwise, have you made network traces from the IIS box to the SQL Server?
What protocols are you using?
Can you reproduce the problem /error using SQL Query Analyser or only from
within IIS?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||I have this EXACT same problem. My ASP app works fine on Win2000, SQL Server 7 or 2000.
I get the same intermittent connection problem only when SQL Server 2000 is on a Win2k3 box. It doesn't seem to be restricted to ASP/IIS6 connections. I have problems with Access 2000 and Enterprise Mgr. as well.
The ASP problem went away when I put SQL Server on the same box as IIS6, but this can only be a temporary solution.
I've scoured the forums as well and I've seen this problem described many times, but no solutions yet.|||same here... I optimised the scripts to reduce the number of queries and I've managed to reduce the number of errors, but I haven't been able to eliminate them.
Windows 2000 used to work fine, but Windows 2003 on upgraded hardware and with a tenth of the number of queries (or less) gives problems.
Sometimes the problem occurs when I'm trying to get a recordset, and sometimes it occurs when I'm connecting to the SQL Server 2000 DB.|||We're having the same problems, except with WScript since moving a
server over to Windows 2003 Server. We are connecting to SQL Server 7
on a local network, specifying TCP/IP in the connection string.
The connection failure is intermittent, but is most easily reproduced
by performing a loop where connections are opened and closed. That
will pretty much guarantee that the error will occur at some random
spot in the loop. Sometimes it fails on the first try, sometimes on
the 415th try. It seems to be completely random.
We have eliminated network issues as a possibility by isolating the
servers onto their own switch and have been able to mitigate the
problem by re-using database connections rather than opening new ones.
Probably we will open a ticket with MS soon.
If anybody has info on a fix, it would help us out tremendously to
hear about it.
Pseudo code to reproduce issue...
begin loop
open database connection
execute a sql statement
close database connection
destroy connection
end loop
MUTU <MUTU.18f155@.mail.mcse.ms> wrote in message news:<MUTU.18f155@.mail.mcse.ms>...
> same here... I optimised the scripts to reduce the number of queries and
> I've managed to reduce the number of errors, but I haven't been able to
> eliminate them.
> Windows 2000 used to work fine, but Windows 2003 on upgraded hardware
> and with a tenth of the number of queries (or less) gives problems.
> Sometimes the problem occurs when I'm trying to get a recordset, and
> sometimes it occurs when I'm connecting to the SQL Server 2000 DB.
|||We're having the same problems, except with WScript since moving a
server over to Windows 2003 Server. We are connecting to SQL Server 7
on a local network, specifying TCP/IP in the connection string.
The connection failure is intermittent, but is most easily reproduced
by performing a loop where connections are opened and closed. That
will pretty much guarantee that the error will occur at some random
spot in the loop. Sometimes it fails on the first try, sometimes on
the 415th try. It seems to be completely random.
We have eliminated network issues as a possibility by isolating the
servers onto their own switch and have been able to mitigate the
problem by re-using database connections rather than opening new ones.
Probably we will open a ticket with MS soon.
If anybody has info on a fix, it would help us out tremendously to
hear about it.
Pseudo code to reproduce issue...
begin loop
open database connection
execute a sql statement
close database connection
destroy connection
end loop
MUTU <MUTU.18f155@.mail.mcse.ms> wrote in message news:<MUTU.18f155@.mail.mcse.ms>...
> same here... I optimised the scripts to reduce the number of queries and
> I've managed to reduce the number of errors, but I haven't been able to
> eliminate them.
> Windows 2000 used to work fine, but Windows 2003 on upgraded hardware
> and with a tenth of the number of queries (or less) gives problems.
> Sometimes the problem occurs when I'm trying to get a recordset, and
> sometimes it occurs when I'm connecting to the SQL Server 2000 DB.
|||
Quote:
We have a classic ASP application which runs fine on NT Server, W2K Server and with SQL7.0 and SQL 2000.
However, we are having problems with IIS6.0 and Windows 2003 Server when connecting to a second Windows 2003 Server running SQL 2000 Server. IIS6.0 and SQL on the same server works fine.
We see intermittent connection problems resulting in:
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
We have tried everything we have found trawling the web and still have no idea what is causing it.
One ASP script in particular that simply updates a table, fails most of the time but does VERY rarely run successfully. The same script NEVER failed under NT/SQL7.0 or W2K/SQL2000.
We have increased timeout settings in IIS and the ASP scripts themselves. We have changed the OLEDB connection to reference the SQL Server IP address instead of its name but nothing tried has made any difference.
Any suggestions would be gratefully received!
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.SqlJunkies.com/newsgroups Our newsgroup engine supports Post Alerts, Ratings, and Searching.
Quote:
I got my information through the microsoft website: http://support.microsoft.com/default...b;EN-US;328383
Here is what helped me:
Specify the protocol in your connection string. For example: "DSN=DSNName;SERVER=servername;DATABASE=YourDataBa seName;Network=DBMSSOCN;Address=IP_Address,1433;UI D=YourUID;PWD=YourPassword;"
In this example, you specify the network protocol as "DBMSSOCN", which means that you want to use the TCP/IP protocol. If you specify the protocol inside your connection string, Dbnetlib only uses the specified protocol and does not try any other protocol. Similarly, to enable Named Pipe protocol only, use a connection string similar to this: "DSN=DSNName;SERVER=servername;DATABASE=YourDataBa seName;Network=DBNMPNTW;Address=\\.\pipe\sql\query ;UID=YourUID;PWD=YourPassword;"|||In case you haven't been told this already....
The intermittant failures smack strongly of TCP/IP ports being
blocked.
A named instance of a server will begin hunting for a TCP/IP Port
between 1025 to 5000. Many of these ports are typical Trojan ports.
You may have read the following:
http://support.microsoft.com/?id=287932
http://support.microsoft.com/default.aspx?kbid=814130
Lou Arnold
Ottawa Canada
On 28 Jun 2004 07:54:29 -0700, jjimenez1984@.yahoo.com (Joel) wrote:
[vbcol=seagreen]
>We're having the same problems, except with WScript since moving a
>server over to Windows 2003 Server. We are connecting to SQL Server 7
>on a local network, specifying TCP/IP in the connection string.
>The connection failure is intermittent, but is most easily reproduced
>by performing a loop where connections are opened and closed. That
>will pretty much guarantee that the error will occur at some random
>spot in the loop. Sometimes it fails on the first try, sometimes on
>the 415th try. It seems to be completely random.
>We have eliminated network issues as a possibility by isolating the
>servers onto their own switch and have been able to mitigate the
>problem by re-using database connections rather than opening new ones.
>Probably we will open a ticket with MS soon.
>If anybody has info on a fix, it would help us out tremendously to
>hear about it.
>Pseudo code to reproduce issue...
>--
>begin loop
>open database connection
>execute a sql statement
>close database connection
>destroy connection
>end loop
>--
>
>
>MUTU <MUTU.18f155@.mail.mcse.ms> wrote in message news:<MUTU.18f155@.mail.mcse.ms>...
|||In case you haven't been told this already....
The intermittant failures smack strongly of TCP/IP ports being
blocked.
A named instance of a server will begin hunting for a TCP/IP Port
between 1025 to 5000. Many of these ports are typical Trojan ports.
You may have read the following:
http://support.microsoft.com/?id=287932
http://support.microsoft.com/default.aspx?kbid=814130
Lou Arnold
Ottawa Canada
On 28 Jun 2004 07:54:29 -0700, jjimenez1984@.yahoo.com (Joel) wrote:
[vbcol=seagreen]
>We're having the same problems, except with WScript since moving a
>server over to Windows 2003 Server. We are connecting to SQL Server 7
>on a local network, specifying TCP/IP in the connection string.
>The connection failure is intermittent, but is most easily reproduced
>by performing a loop where connections are opened and closed. That
>will pretty much guarantee that the error will occur at some random
>spot in the loop. Sometimes it fails on the first try, sometimes on
>the 415th try. It seems to be completely random.
>We have eliminated network issues as a possibility by isolating the
>servers onto their own switch and have been able to mitigate the
>problem by re-using database connections rather than opening new ones.
>Probably we will open a ticket with MS soon.
>If anybody has info on a fix, it would help us out tremendously to
>hear about it.
>Pseudo code to reproduce issue...
>--
>begin loop
>open database connection
>execute a sql statement
>close database connection
>destroy connection
>end loop
>--
>
>
>MUTU <MUTU.18f155@.mail.mcse.ms> wrote in message news:<MUTU.18f155@.mail.mcse.ms>...
No comments:
Post a Comment