Database Mirroring también está disponible para conexiones ODBC; recuerda que para que la aplicación cliente sepa a qué servidor intentar "re-conectar", en algún sitio en su configuración debe conocer los servidores miembros.

Puedes cambiar la cadena de conexión de tu aplicación usando la siguiente sintaxis:

• Server=instancia_servidor_principal;
• Failover Partner=instancia_servidor_mirror;

Cambiar la cadena de conexión, es posible que no requiera recompilar la aplicación si lo gestionas a través de ficheros INI, pero en las "viejas" aplicaciones VB6, no se utilizaba esta técnica con demasiada frecuencia por lo que con bastante probabilidad requeriría recompilación de la aplicación.

Como debes saber, las APIs de acceso a datos también implementan Mirroring para ODBC, por lo que si tienes DSNs de usuario también es muy fácil de cambiar; tan sólo tendrás que cambiar el Driver al nuevo Driver SQL Native Cliente (fíjate en esta primera pantalla el elemento seleccionado):

Y luego, en la configuración de la base de datos a la que deseas conectar, tienes la posibilidad de establecer cual es servidor mirror (en el caso de ejemplo sería DELL-ERH\INSTANCE2):

Otras consideraciones interesantes que comenté en la presentación de ayer de nuestro SQL Summit:

• Recuerda que cuando tu aplicación conecta al servidor principal, el servidor principal envía a la aplicación cliente quien es el servidor mirror: en este caso la información que tienes en la cadena de conexión, las APIs de acceso a datos no la necesitan porque tiene de primera mano (el servidor principal) quien es el servidor mirror.
• La información que tienes en la cadena de conexión del servidor mirror, solamente será utilizada cuando el primer intento de conexión no se puede satisfacer contra el servidor principal. SOLO en este caso, tirará de la información que tiene de la cadena de conexión.

En SQL Server 2008, (según comentan los whitepapers iniciales), no será necesario codificar quien el servidor mirror porque "milagrosamente" la aplicación cliente tendrá cacheada esa información. Digo "milagrosamente", porque no conozco todavía el mecanismo que utilizarán para cachear esa información. Recuerdo que en las primeras fases betas de SQL Server 2005, implementaban un mecanismo similar, pero con el paso del tiempo la implementación se quitó del producto por razones que desconozco.

Mi opinión personal es que el comportamiento que se promete para SQL Server 2008, es el comportamiento que "debería ser" J