Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am putting a HA SQL server environment up based on three SQL Server 2008 R2 machines and database mirroring.

I'll name them :


The "company.intra" domain is the holding company's domain.

Both database engines are listening on the static 52002 port so client applications access them the following way :,52002 &,52002

Endpoints are called EP_Mirroring at principal and mirror, EP_Witness at witness and listen on the 5022 port at principal, 5023 at mirror and 5024 at witness.

Service accounts are correctly configured and granted connect permissions on each other's endpoints.

The mirroring feature is working fine, and databases correctly failover in case of TSQL manual failover or simulated system failure.

The problem is with applications behaving strangely upon failover.

The application testing context is the following :

A small .NET app consisting of two textboxes and a button :

When the button is clicked, it makes a stored proc call and fills Textbox1 with the sp's output and Textbox2 with the Data source property of my SqlConnection.

The connection string looks like :

initial catalog = TEST_FAILOVER;user ID=user;password=pass;Connection Timeout=30

I launched this app from my laptop, located in another domain :

Scenario 1:

  1. I launch the app
  2. Button pressed, TB1 : sp output / TB2 :,52002
  3. Database Failover
  4. Button pressed, connection timeout
  5. Button pressed, connection timeout
  6. DB Failover at mirror (back to principal)
  7. Button pressed, TB1 : sp output / TB2 :,52002

Scenario 2:

  1. Database Failover
  2. Launching the app
  3. Button pressed, TB1 : sp output / TB2 :,52002
  4. Database Failover at mirror (back to principal)
  5. Button pressed, connection error
  6. Button pressed, TB1 : sp output / TB2 :,52002
  7. Database Failover
  8. Button pressed, connection timeout
  9. Button pressed, connection timeout

I then tried to launch the app on the mirror server, locally via RDP

Scenario 3

  1. Launching the app
  2. Button pressed, TB1 : sp output / TB2 :,52002
  3. Database Failover
  4. Button pressed, connection error
  5. Button pressed, TB1 : sp output / TB2 : MIRROR

I checked MSDN for Ole DB connectivity behavior in case of failover to understand why in the third scenario the data source property of my connection was set to MIRROR and not,52002

I learned that the failover server property of my connection string is only used in the case of an initial connection to the principal failing (explaining why scenario 2 correctly worked), but that in the case of an existing connection, the principal server has already provided the app with the mirror server address (in something called "failover cache"); the provided information is wrong, no listening port information and host name instead of FQDN thus failing outside the holding company domain.

Next step, I checked the sys.database_mirroring view :

select M.* 
from sys.databases D 
inner join sys.database_mirroring M on D.database_id = M.database_id 

And noticed that the "mirroring_partner_instance" field containes "MIRROR" instead of ",52002".

A quick check to Books Online informed me that this is the field used to inform client apps of the failover partner upon initial connection to the principal DB Engine.

So, finally, my question is :

Is there a way to correct that behavior, and make the "mirroring_partner_instance" field hold the FQDN of the mirror, with the listening port?

At endpoint creation? At mirroring configuration level (via an alter database statement)? DB Engine configuration?

I already successfully tried setting up a SQL Server Native client alias at client computers as a workaround, however I'd really prefer if the principal server returned the correct failover information to client applications.

share|improve this question
I am facing this exact same scenario where I sometimes see the computername in the connection string and not the FQDN and very sad to see it unanswered two years later. I've worked around by using a hosts file but that's not ideal. Did either of you happen to resolve the issue? – ss2k Jul 29 '15 at 10:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.