SQL Native Client Automatic Failover Only Works When Both Servers Are Plugged In
Dec 9, 2006
I have setup a database mirroring session with witness - MachineA is the principal, MachineB is the mirror, and MachineC is the witness. Each SQL Server instance is hosted on its own machine. The mirroring is working correctly. If I submit data to the database on MachineA, and then unplug the network cable on MachineA, MachineB automatically becomes the principal, and I can see the data that I originally submitted to MachineA on MachineB. All the settings are showing correctly in Management Studio.
My issue is with the SQL Native Client and a front-end application that needs to make use of this database. I have setup my front-end application to use the ODBC client and specified the failover server in both the ODBC setup and the connection string. Here is the connection string that I am using :
Everything works perfectly on my front-end application when MachineA is the principal. If I unplug the network cable on MachineA, MachineB becomes the principal, and the failover occurs correctly on the database side. The problem is that my front-end application is not able to query the database on MachineB.
BUT - if I plug the network cable back in on MachineA (making the database on MachineA the mirror), the front-end application now works and can access the principal database on MachineB. I wrote a quick tester application to verify what I am seeing, and I am convinced that this is what is happening. The mirroring is working perfectly, and everything is setup correctly. The SQL Native Client is setup correctly. The problem is that the automatic failover to MachineB that is built into the SQL Native Client only works if both servers are plugged in.
In this scenario, when I plug both servers in, I know that the front-end app is definitely pulling from MachineB (since the mirror database on MachineA is in recovery mode, it's unavailable, and the front-end app displays the server that it is pulling data from).
Am I using an out-dated SQL Native Client? The version number displayed in the ODBC configuration page is 2005.90.2047.00, and is dated 4/14/2006. Has anyone experienced this issue? I'm guessing that it's a problem in the SQL Native client, since the mirroring really seems to be working correctly.
We have set up Mirroring with a witness server and everything works fine when we failover from the SQL Management console.
However, if we failover when our Maccola client is connected, the client blows up - clearly because it can no longer connect to the database.
The ODBC DSN used by the Maccola client shows a checkbox for the 'select a failover server' but the checkbox is grayed out.
Also the summary of settings for the DSN at the end of the wizard reveals that the failover to server (y/N) option is set to N.
The default setting for this DSN is 'populate the remaining values by querying the server' but it doesn't appear to be getting the settings for failover from the server or any other interactive DSN settings either. The server is clearly set for mirroring.
Another suspicious item is that the DSN cannot connect to the server with SA permissions, even though the server is set to mixed security and we use the correct authentication.
Is it possible that the client MACHINE is not authenticating with the domain or sql server properly. We are logged into the client with the domain account that is the SQL admin account on the sql server box.
We should be able to interact with the sql server settings through the ODBC DSN on the client shoulnd't we?
Product: Microsoft SQL Server 2005 -- Error 29515. SQL Server Setup could not connect to the database service for server configuration. The error was: [Microsoft][SQL Native Client]Encryption not supported on the client. Refer to server error logs and setup logs for more information. For details on how to view setup logs, see "How to View Setup Log Files" in SQL Server Books Online.
On Windows XP systems I get the following issue when trying to browse the MSDB folder in SSIS
Client unable to establish connection Encryption not supported on SQL Server. (Microsoft SQL Native Client)
I have noticed another post where several others have noticed the same issue. It appears to only occur on Windows XP installations. Is there a workaround or fix for this?
I have SQL2000 installed as the default instance, and now I'm trying to install SQL 2005 standard edition as a named instance.
I receive this error : SQL Server could not connect to database service for server configuration.. [SQL Native client] Encryption not supported on the client. However I'm able to install client tools
The setup works fine on other box with the same config : SQL 2000/Windows XP, is there any work around for this issue ?
In my SQL 2000 client network utilty "Force proctocol encryption " is desabled and did not find the setting for SQL 2005 !
Hi there, I am testing the db mirroring, making sure it will auto failover. I've stopped the SQL services on my principal and then I looked at the mirror db is says it's restoring. It stayed like that for 10 min before I enabled the mirroring again. Anyone knows why it's not failing over??????
Here's my setup: SQL 2005 Standard, Server 1 Principal, Server 2 Mirror & Witness.
We've recently set up a Principle, Mirror and Witness configuration with the Mirror and Witness in a separate building to the Principle. All three are part of the same domain (DMZ) and are different servers, the buildings are connected via a fiber optic cable. All servers and SQL Server instances are logged in with the same domain admin account DMZesAdmin.
Mirroring is all set-up and the databases are synchronized. Every once in a while some (not all, normally 6 out of 15) databases will switch roles and become active on the mirror. The SQL Server mirroring monitor job then reports:
Date 25/01/2007 12:37:01 Log Job History (Database Mirroring Monitor Job)
Step ID 1 Server DMZSQL01 Job Name Database Mirroring Monitor Job Step Name Duration 00:00:02 Sql Severity 16 Sql Message ID 32038 Operator Emailed Operator Net sent Operator Paged Retries Attempted 0
Message Executed as user: DMZesadmin. An internal error has occurred in the database mirroring monitor. [SQLSTATE 42000] (Error 32038). The step failed.
I have no idea, what causes the failover, it could be a slow network or a bad set-up, can anyone give me some ideas of what to do to track down the problem or any experience of what could be causing this, it happens randomly every day or three. No warning and if I go to the mirror and failover back to the principle again then it's all just fine. However I don't want half my databases working on 1 server and half on the other.
Any ideas?
Thanks Ed
UPDATE:
I've just been looking at the logs on my Mirror and at the same time it reports in this order
Error: 1479, Severity: 16, State: 1.
The mirroring connection to "TCP://DMZSQL01.dmz.local:5022" has timed out for database "WARCMedia" after 10 seconds without a response. Check the service and network connections.
Database mirroring is inactive for database 'WARCMedia'. This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database 'WARCMedia' (41). This is an informational message only. No user action is required.
The mirrored database "WARCMedia" is changing roles from "PRINCIPAL" to "MIRROR" due to Failover.
Database mirroring is inactive for database 'WARCMedia'. This is an informational message only. No user action is required.
...
This looks like a time out, is there any way to set the TimeOut threashold for Database mirroring or set retry intervals??
I have a report that was designed using SQL Reporting Services that sits on a SQL reporting server. It's nothing too exciting, it is essentially a three page application with legal jumbo on pages 2 and 3 and applicant data in fields on page 1.
We use rectangles to force page breaks to page 2 and to page 3.
When running the report on the report server, it shows and prints fine.
When running the report from the QA website internally, it shows and prints just fine.
When running the report from the production website from a machine internally, it shows and prints just fine.
When running the report from outside of the company network, the report is jacked. It obliterates large chunks of text, crams text together, and creates blank pages.
I need help in determining where I even begin with trouble shooting this!
3 servers - PRINCIPAL IP: 10.2.5.31 - DNS Lookup: db-server-2.mosside.choruscall.com - MIRROR IP: 10.2.5.30 - DNS Lookup: sql-mirror.mosside.choruscall.com - WITNESS ip: 10.2.5.32 - DNS Lookup: sql-witness.mosside.choruscall.com
Each Server is running Windows Server 2003 Enterprise Edition with SQL Server 2005 Enterprise Edition. All server instances are enabled for remote connections(By default they are not). All servers have the flag 1400 traceon and have been restarted. PORT 5022 is unrestricted on network.
The server instances are connecting via certificates. Each server has an endpoint for the certificates to to connect on.
Certificate Setup Proceedure:
Principal_Host:
1. Create Master Key with Password
2. Create certificate with subject
3. Create endpoint for certificate (Listener_Port = 5022, Listener_ip = all) to connect on for database_mirroring
4. Backup Certificate (principal_cert.cer)
5. Take backed up certificate to Mirror_Host
(Reapeat Steps 1-5 for Witness and Mirror)
Mirror_Host: Create Certificate on Mirror_Host for inbound connections from Principal:
6.(On Mirror_Host) Create Login for Principal using same password in step 1 (principal_login)
7. Create user for login just created. (principal_user)
8. Create local certificate for Principal on Mirror using certificate generated by principal.
ex: Create Certificate Principal_cert Authorization Principal_user FROM FILE='c:principal_cert.cer'
9. (If an endpoint has been created already on the mirror)Grant connectiion to the login:
ex: Grant connect on endpoint::mirror_endpoint to principal_login
Repeat Steaps 6-9 for Principal and Witness Servers accordingly.
10. Import Database to SQL Server 2005 Principal Instance
11. Backup Database to disk with format
12. Backup Database log file to disk with format
13. Copy backups to mirror
14. Restore Database and log file with norecovery on Mirror_Host
15. Configre Database for Database Mirroring on Principal Server
There are two ways to do this. Via the wizzard or via the Transact-SQL window. Using the wizzard appears to work since I started using FQDN.
PROBLEM:
After configuration, everythig appears to be correct. That is, the principal displays that it is the principal and it is synchronized with the mirror. The mirror also displays that it is the mirror and it is synchronized with the principal and it is in recovery. If I failover manually, the mirror becomes the principal and the principal becomes the mirror (They form a quarum). If I disconnect the principal from the network, the mirror is supposed to form a quarum with the witness and promote itself to principal status. This is not what is happening. The witness recognizes that the principal is down and logs that info into its log file. The Mirror attempts to contact the witness but cannot log onto the machine. The Mirror Logs the following:
Error: 1438, Severity: 16, State: 2. The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry.
<<<<<<<MIRROR SERVER >>>>>>>>
2007-09-06 15:08:45.32 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:08:45.32 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:09:05.32 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:09:05.32 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:09:25.33 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:09:25.33 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:09:45.34 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:09:45.34 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:10:05.35 spid23s Error: 1438, Severity: 16, State: 2. 2007-09-06 15:10:05.35 spid23s The server instance Witness rejected configure request; read its error log file for more information. The reason 1451, and state 3, can be of use for diagnostics by Microsoft. This is a transient error hence retrying the request is likely to succeed. Correct the cause if any and retry. 2007-09-06 15:10:25.36 spid23s Error: 1438, Severity: 16, State: 2.
<<<<<<< WITNESS SERVER >>>>>>>>
2007-09-06 14:19:55.90 spid52 The Database Mirroring protocol transport is now listening for connections. 2007-09-06 15:07:11.64 spid24s Error: 1479, Severity: 16, State: 1. 2007-09-06 15:07:11.64 spid24s The mirroring connection to "TCP://db-server-2:5022" has timed out for database "APS_SQL_DEV" after 10 seconds without a response. Check the service and network connections. 2007-09-06 15:07:43.20 Server Error: 1474, Severity: 16, State: 1. 2007-09-06 15:07:43.20 Server Database mirroring connection error 4 '64(The specified network name is no longer available.)' for 'TCP://db-server-2:5022'. 2007-09-06 15:08:06.03 spid9s Error: 1474, Severity: 16, State: 1. 2007-09-06 15:08:06.03 spid9s Database mirroring connection error 2 'Connection attempt failed with error: '10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)'.' for 'TCP://db-server-2:5022'.
we're running a mirrored database with High Availability for Automatic failover including a Witness instance for a web application.
When doing a manual failover on the database in Management studio, the roles are switched correctly and the database is in "Principal, Synchronized" and "Mirror, Synchronized/Restoring" mode. The web application has no problems switching servers by using client failover with the jdbc driver. There is no problem accessing the database with Management Studio.
However, if we stop the SQL service on the Principal server the role is automatically failed over to the Mirror server by the Witness. The database is then in the mode "Principal, Disconnected" which should be fine. However, accessing the database from the web application or with Management Studio yields some strange results. It is not possible to write to the database, and reading from the database works inconsistently (the web application seems like it can do it, but not from the Management Studio).
Starting the SQL service on the former Principal server makes the database go into mode "Mirror, Synchronizing/Restoring" and "Principal, Synchronizing". And it will stay that way indefinitely. There are not that many updates/transactions made to the database that can make it stay in this state, especially if you can't write to the database in the first place.
The next step taken after being stuck in this state is to stop the SQL service on the Mirror (former Principal), restart the service on the Principal (former Mirror). Accessing the database now works. The database is in mode "Principal, Disconnected". Starting the SQL service on the Mirror (former Principal) makes the database go into the normal "Principal, Synchronized" and "Mirror, Synchronized/Restoring" mode. Access to database is normal.
The same erroneous behaviour can be observed by unplugging the network cable on the Principal server, so it seems like we can only get a smooth transition by doing a manual failover.
Any ideas on what might be the problem? Has anybody experienced a similar situation?
I'd like to understand why it is not possible to automatic Failover Availability Groups using Failover Cluster Instances. I think it would be great for DR and HA. Do you understand why that limitation exists?
The link [URL] ....
SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.
I have setup a mirror configuration with a witness to be able to use the automatic failover. The principal is DBSP01, the mirror is DBSP02 and the witness is DBSP03. I have an application running an DBCP01. When the mirroring is working, the application can connect to the database on DBSP01. I disconnect dbsp01 from the network, so that DBSP02 becomes the principal. When I try to connect the application to the database on DBSP02, the login fails. Whithout the mirroring I was able to logon to DBSP02, but as soon as it is part of the mirroring, I'm not able to connect to it anymore, whatever the state of the database is. What could be the problem? Can anybody help?
I have tried this on several different operating systems (VISTA and XP ) and several versions of SQL NATIVE CLIENT including 2005.90.3042.0
I have a 64 bit "SQL NATIVE CLIENT" connection that fails. The exact same connection and code succeeds on 32 bit. My customer and I prepend "oledb:" to the connection string and it starts working.
FAILS on 64 bit: Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Wrigley_Test;Data Source=MONGO;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=RIPTIDE;Use Encryption for Data=False;Tag with column collation when possible=False;MARS Connection=False;DataTypeCompatibility=0;Trust Server Certificate=False
WORKS oledb:Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Wrigley_Test;Data Source=MONGO;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=RIPTIDE;Use Encryption for Data=False;Tag with column collation when possible=False;MARS Connection=False;DataTypeCompatibility=0;Trust Server Certificate=False
I debugged my code to the point that I know it is happening when I call CreateAccessor for my SQL statement.
I have a 3 node 2014 AlwaysOn setup. The primary and secondary are set for automatic failover. The third node, of course, is manual (until 2016). The 2 nodes with are automatic are sitting in one datacenter, the third is in another. If the first datacenter was to go down, I would manually have to failover to the third node? What's the normal process here for having two datacenters and ensuring the availability group is always available?
In an sql authentication environment with an automatic failover in database mirroring how to you manage new logins which have been created on the principle since the start of mirroring? Since the master cannot be mirrored, and the mirror database cannot be read during mirroring (except as a snapshot) in order to find the missing logins, I assume that only after failover a script should run to create the new logins and then run sp_change_users_login . The qestions are:
1) should the script create a new login first and then run sp_change_users_login with option update_one , or should sp_change_users_login using option
Auto_Fix create the missing logins?
2) But what is the password of these users? is it initially NULL , as a consequence of sp_change_users_login? What about the SIDs?
3) Or should we bypass sp_change_users_login altogether and use
CREATE LOGIN <loginname> WITH PASSWORD = <password>, SID = <sid for same login on principal server>,...as described in http://blogs.msdn.com/chadboyd/archive/2007/01/05/login-failures-connecting-to-new-principal-after-failover-using-database-mirroring.aspx
4) What is the event that would trigger this script to run after the aitomatic failover ?
Is there a definitive MIcrosoft agreed apon and recommended method to tackle this?
I'm looking for a solution to have cross data center automatic failover in the event of a data center loss for highly critical databases. I would like to have local HA and also automatic failover to the DR site. This does not seem possible with AlwaysOn.
Is my only option for automatic cross data center failover to build a node in one data center and a node in the other data center with a node/FS at a third data center in order to maintain quorum? I'd like to have local HA in the mix but that doesn't seem possible.What pattern for the highest data security and also availability?
An automatic failover set exists. This set consists of a primary replica and a secondary replica (the automatic failover target) that are both configured for synchronous-commit mode and set to AUTOMATIC failover.Configured the both AG Group database automatic failover and synchronous-commit mode.But automatic Failover failed also Cluster service not started automatically at Node2. It got connected through AO Listerner after starting Node1. As below SQL Error log during shutdown Node1
Date,Source,Severity,Message 10/27/2015 10:44:20,spid37s,Unknown,AlwaysOn Availability Groups: Waiting for local Windows Server Failover Clustering node to come online. This is an informational message only. No user action is required. 10/27/2015 10:44:20,spid37s,Unknown,AlwaysOn Availability Groups: Local Windows Server Failover Clustering node started.
I am a C++/C# developer my SQL skills are very limited. I have a database set up for mirroring and I would like to get an e-mail notification whenever an Automatic Failover occurs. Can anyone show me how to do this using SQLServer 2005? Please provide T-SQL script sample if possible!
Does anybody knowk if it's necessary to upgrade Sql Native Client to conect to a Server when you has upgrade it to Sql 2005 SP2? That is to say, can you conect to a Sql server 2005 SP1 and to a Sql Server 2005 SP2 from a client with the same Sql Native client or you have also to upgrade it?
We have a VB6 app that we're trying to connect to an SQL2005 server.
We're able to connect from dev machines that have SQLExpress, or SQL 2005 tools installed, but we cannot connect from other machines. We've installed sqlncli.msi from the MS site, but this still doesn't work. When we try to login, we get an error that reads "0[Microsoft][SQL Native Client]Fractional truncation" when we try writing to a smalldatetime field. This problem does not happen on the dev machines.
Connection string:
connectiontype = cnnSQLServer
database name = name
pasword = password
userid = uid
servername = servername
driver = {SQL Native Client}
Driver version on the dev machines is: 2005.90.3042.00
Driver version on the roll out machines is: 2005.90.1399.00
We're upgrading from SQL2K to 05 next week. We want to push the SQL Native Client driver(ODBC) thru the network but IT said it can only be an msi or exe file. Is their anyway we could get this file in this format?
I'm new in this forum and I 'm Italian, so my English won't be perfect!
If i want to connect to my SQL Server database in prompt i type:
"osql -U sa" and then i type the password. So, I get an error that says:
"[Sql Native Client] Provider Via: Impossible to find the specified module. [Sql Native Client] Access timeout expired [Sql Native Client] An error occured during the attempt to estabilish a connection to the server. During the connection to SQL Server this error may be caused by pre-defined settings that don't ......"
How i can solve this problem? Who can help me? Thank you!!
Can I use the "SQLOLEDB" provider to connect to a SQL Native Client? Follow-up question: does the "SQLOLEDB" provider use the same TDS transport protocol as the SQL Native Client provider?
The Clients Environment: Windows Server 2003 R2 SQL Server 2005 SP1 Standard Edition Version 9.00.2153.00 SQL Native Client Version 2005.90.2047.0
My Development Environment Windows XP SQL Server 2005 SP1 Developer Edition Version 9.00.2047.0 SQL Native Client Version 2005.90.3042.0
The Error: [Microsoft] [ODBC SQL Server Driver] Fractional truncation
We have tons of VB 6 legacy code. (I know.. we are trying to get it to .Net.. just not enough time in the day) We recently installed our application at a cleints site (environment listed above) and all of a sudden we are getting errors every time we execute a rs.update using ADODB. I have pasted an example below. The kicker is that it runs fine in my development environment. I can get around this issue by using a command object to do the insert, but we have thousands of these sprinkled throughout the application and would take weeks to change them over; and of course this client demands to start using our application NOW. I am inclined to think that it is an issue with SQL Client since it does not appear to have been updated when the SP1 was installed. I have read some blogs about issues with SQL Native Client and datetime values.
'Broke Code Dim RS as New ADODB.Recordet Dim SQL as String Dim datGetDate as Date
'THis select statement return an empty recordset. ID is an identity column SQL = "SELECT * FROM table WHERE id is null RS.Open SQL, gadoConn,adOpenKeySet, adLockOptimistic RS.AddNew RS("col1")=Value1 RS("col2")=Value2 RS("starttime")=datGetDate RS.Update 'This is where it blows RS.Close
'New and Improved code. Works perfectly Dim SQL as String Dim objCMD as new ADODB.Command
When i try to query for Column precision using SQL Native Client ODBC Driver it returns '0' instead of 2^31-1 (which is the value for MAX), but when i use other driver it works as expected. If i assign some value like varbinary(20) then it works.
Please let me know is there any fix pack available for this. Because one of our client is facing this problem, so we have to provide solution as early as possible:
I'm new in this forum and I 'm Italian, so my English won't be perfect!
If i want to connect to my SQL Server database in prompt i type:
"osql -U sa" and then i type the password. So, I get an error that says:
"[Sql Native Client] Provider Via: Impossible to find the specified module. [Sql Native Client] Access timeout expired [Sql Native Client] An error occured during the attempt to estabilish a connection to the server. During the connection to SQL Server this error may be caused by pre-defined settings that don't ......"
How i can solve this problem? Who can help me? Thank you!!
How can I check "Native client" is present on my client? I'm trying to eliminate all the reasons my client won't run a VC++ app which access a sql server.
We are using SQL Server 2005 (9.0.3054 on Windows 2003 RC2 SP2 with clustering two instances. We are running an instance on both boxes. I have 2 linked servers to the same server on the first box (SQL1C) that use different SQL Logins to connect to the same box but to different databases. One uses the name of the server and one uses the name of the server with a 2 at the end of it. (servername and servername2). The second linked server was added recently and is used very frequently by the new application. The other thing is there is a server with the name servername2. They are SQL boxes but I am not sure what version or what they are running on. If it turns out to be important, I will ask.
Here's what is happening: When we fail over to the second box, up until recently, we had no problems. All linked servers worked well. But since we have added this new linked server, when we fail over, the linked server no longer works and we get an error like from the Cold Fusion application:
[Macromedia][SQLServer JDBC Driver][SQLServer]TCP Provider: An existing connection was forcibly closed by the remote host.
I got a similar error in EMS, but did not copy it to save it. Since this is a production server, I can't really just try things.
We checked to make sure all IPs from box1 and box2 are allowed access to the server and they are not using IP blocking for inside the university domain.
There are no errors in the SQL Logs. I checked the application logs and found no errors for the linked server. The only error I could find and I didn't think it was related but I will include it was this:
Closed event notification conversation endpoint with handle '{4F54167A-F3D0-DC11-97FE-000E0CB2D7CA}', due to the following error: '<?xml version="1.0"?><Error xmlns="http://schemas.microsoft.com/SQL/ServiceBroker/Error"><Code>-8470</Code><Description>Remote service has been dropped.</Description></Error>'.
Any ideas? One of our pplications goes down when the cluster fails over now. Help PLEASE!
When using Named Pipes the issue is no longer there.
On massive batch inserts we sometimes get a long pause at the end of one insert and before begining the next one. Example:
1000 inserts in the same table and then repeat. This will work fine for 3 or 4 iterations, then pause during the 5th iteration for up to 40 seconds and then simply continue.
When this exact same procedure is done using Named Pipes as the connection method this never happens.
While this is happening neither the server or the workstation is doing anything, 0% CPU, 0% network, it just sits there.
All this using the SQL Native Client 2005 and ADO.
I cannot connect to my SQL2005 server using the old SQL ODBC drivers, I have to use the Native client drivers. The database I am trying to connect to is a SQL 2000 db I just attached. Its owner is a SQL user login, which works fine and can connect remotely.