17 marzo, 2010

Fin de soporte a algunas versiones de Windows

El soporte a algunas versiones de Windows llegarán a su fin en los próximos meses de 2010. Veamos cada una:

  • Windows 2000 Professional y Windows 2000 Server: 13 de Julio de 2010.
  • Windows XP + Service Pack 2: 13 de Julio de 2010. Acción inmediata: Instalar Service Pack 3.
  • Windows Vista sin Service Pack: 13 de Abril de 2010. Acción inmediata: Instalar Service Pack 2.

Más información:

http://blogs.technet.com/lifecycle/archive/2010/02/24/end-of-support-for-windows-xp-sp2-and-windows-vista-with-no-service-packs-installed.aspx

Service Pack 3 for Windows XP:
http://www.microsoft.com/downloads/details.aspx?FamilyID=68C48DAD-BC34-40BE-8D85-6BB4F56F5110&displaylang=en

Service Pack 2 for Windows Vista: http://www.microsoft.com/windows/windows-vista/default.aspx

04 marzo, 2010

Diagnóstico de problemas de conexión a SQL Server 2005/2008, Parte 3

/*
Este post muestra cómo diagnosticar problemas de conexión a SQL Server usando cliente MDAC, según sea el mensaje de error obtenido. El post original en inglés fué realizado por Ming Lu y publicado en http://blogs.msdn.com/sql_protocols/archive/2005/10/29/486861.aspx

He realizado la traducción a español y algunas aclaraciones mínimas para dar mayor claridad.
*/

En este artículo mostraremos cómo diagnosticar problemas de conexión a SQL Server 2005/2008, usando el cliente MDAC y según sea el mensaje de error recibido. Este artículo es la continuación de:

Diagnóstico de problemas de conexión a SQL Server 2005/2008, Parte 2
http://ascii164.blogspot.com/2010/02/diagnostico-de-problemas-de-conexion.html

En la Parte 1 se mostró cómo diagnosticar problemas generales de conexión, especialmente desde el punto de vista de red.

Luego en la Parte 2 vimos los errores producidos usando el cliente SNAC. En esta parte vamos a tratar con los errores usando el cliente MDAC.

Cuando descubrimos que las conexiones a SQL Server 2005/2008 fallan a través de un cliente MDAC, primero hay que estar seguro que el servidor SQL está accesible y que la instancia está iniciada; segundo, identificar qué protocolos están habilitados en el servidor; finalmente revisar los casos de estudio que se muestran.

Lo primero que nos preguntaremos es ¿Cómo sabemos si la aplicación usa el cliente MDAC o el cliente SNAC?

Si sabemos el string de conexión de la aplicación, podemos saber el cliente usado según lo que se haya especificado en las etiquetas Driver y Provider:

MDAC ODBC

DRIVER= {SQL Server}; SERVER=xx; Trusted_connection=yes; Connect Timeout=30

MDAC OLEDB

Provider= SQLOLEDB; Data Source=xx; Integrated Security=SSPI;Connect Timeout=30

SNAC ODBC

DRIVER= {SQL Native Client}; SERVER=xx; Trusted_connection=yes; Connect Timeout=30

SNAC OLEDB

Provider=SQLNCLI; Data Source=xx; Integrated Security=SSPI; Connect Timeout=30

Cuando no conocemos el string de conexión de la aplicación, debemos observar el texto del mensaje de error.

Ejecutar:

osql /Sxxx /E (donde “xxx” es un servidor desconocido)

El resultado obtenido cuando el cliente es MDAC es el siguiente:

[DBNETLIB]SQL Server does not exist or access denied.

[DBNETLIB]ConnectionOpen (Connect()).

-o-

[DBNETLIB]Specified SQL server not found.

El resultado obtenido cuando el cliente es SNAC es:

Named Pipes Provider: Could not open a connection to SQL Server [53]

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.

Para identificar la versión de MDAC que hay instalada en la máquina cliente, visitar estos documentos en el sitio de Soporte de Microsoft:

http://support.microsoft.com/default.aspx?scid=kb;en-us;231943

http://support.microsoft.com/default.aspx?scid=kb;en-us;301202

MDAC no brinda mensajes de error tan claros como los de SNAC, lo cual dificulta en cierta medida el diagnósitco de problemas de conexión. Veamos cada mensaje y algunas recomendaciones para diagnosticar el problema en base a los protocolos configurados en SQL Server.

Mensaje 1:

[DBNETLIB]SQL Server does not exist or access denied.

Mensaje 2:

[DBNETLIB]Specified SQL server not found.

Mensaje 3:

[DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation.

Diagnóstico:

Primero hay que saber cuáles son los protocolos configurados en el servidor, y asegurarse que el servicio SQL y el servicio SQL Browser están iniciados. Hay dos formas posibles de revisar eso:

1. Ir al SSCM( SQL Server Configuration Manager ), click en “protocols for ”, y ver allí el estado de cada protocolo soportado en el servidor.

2. Revisar el archivo de errores de SQL Server.

2.1. Está habilitado el protocolo Shared Memory (SM) cuando dice:

Server local connection provider is ready to accept connection on [\\.\pipe\SQLLocal\MSSQLSERVER] o [ \\.\pipe\SQLLocal\instancia;]

2.2. Está habilitado el protocolo Named Pipes (NP) cuando dice:

Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$instancia\sql\query ] o [ \\.\pipe\sql\query ]

Notar que pueden aparecer esos textos aún cuando solamente esté habilitado SM. Para estar seguro de que el servidor remoto tiene habilitado NP, probar la conexión vía el NP:

osql /S\\maquina\pipe\sql\query /E

-o-

osql /S\\maquina\pipe\MSSQL$instancia\sql\query /E

Solamente cuando la conexión es exitosa significa que el servidor está escuchando en NP.

2.3. Está habilitado TCP/IP cuando dice:

Server is listening on ['any' ipv4; numeropuerto;]

[ direccionIP; ipv4; numeropuerto;].

El primer mensaje es cuando se ha habilitado en el servidor la opción “ListenonAllIPs”, y la segunda es cuando el servidor está escuchando en una dirección IP individual. Para verificar más, revisar si SQL Server está escuchando en el puerto exacto, usando el comando NETSTAT:

netstat -ano ! findstr numeropuerto

Las siguientes recomendaciones para diagnosticar se basan en cuál protocolo está habilitado. Ante un error de conexión, primero identificar cuál es el protocolo configurado en el servidor SQL.

NOTA 1: Todos los casos aplican tanto a una instancia sin nombre como a una instancia nombrada. Si se trata específicamente de una instancia nombrada, se indicará en forma explícita.

NOTA 2: Normalmente hay 3 partes en los campos “Server” o “DataSource” del string de conexión: [prefijo]servidor\[instancia], los valores de servidor; pueden ser algunos de los siguientes:

  1. “.”
  2. “(local)”
  3. “localhost”
  4. nombremaquina
  5. “127.0.0.1”
  6. FQDN(Server Fully Qualified Domain Name)
  7. direccionIP

ESTUDIO DE CASOS BASADOS EN MDAC

Los casos siguientes cubren los casos de clientes MDAC 2.8/2.81/2.82 conectándose a SQL Server 2005/2008 instalado en Windows 2000/2003/XP.

Veamos cada caso según estén habilitados o no, los protocolos Shared Memory (SM), TCP/IP y Named Pipes (NP).

CASO 1: Solamente está habilitado SM

Diagnósticos:

1.1. Se especificó el prefijo “tcp:” en el string de conexión, pero TCP/IP no está habilitado. Para solucionar esto, quitar el prefijo o habilitar TCP/IP.

1.2. Se especificó el prefijo “np:” en el string de conexión, además se especificó como servidor “localhost”, un FQDN, “127.0.0.1” o la dirección IP. Para solucionar esto, o bien habilitar NP o especificar como servidor “nombremáquina”.

1.3. Se especificó como servidor “localhost”, un FQDN, “127.0.0.1” o la dirección IP. Para solucionar esto especificar como servidor “nombremáquina”.

1.4. Se especificó el prefijo “lpc:” en el string de conexión, además se especificó como servidor “localhost”, un FQDN, “127.0.0.1” o la dirección IP. Para solucionar esto, especificar como servidor “nombremáquina”.

1.5. Se usa el proveedor OLEDB, luego se conecta a la instancia por omisión usando “.” o “(local)”. Para solucionar esto, especificar como servidor “nombremáquina”.

CASO 2: SM y TCP/IP habilitados, NP no habilitado

Diagnósticos:

2.1. Se especificó el prefijo “np:” en el string de conexión, además se especificó como servidor “localhost”, un FQDN, “127.0.0.1” o la dirección IP. Para solucionar esto, o bien habilitar NP o especificar como servidor “nombremáquina”.

2.2. Se especificó el prefijo “lpc:” en el string de conexión, además se especificó como servidor “localhost”, un FQDN, “127.0.0.1” o la dirección IP. Para solucionar esto, especificar como servidor “nombremáquina”.

CASO 3: SM y NP habilitados, TCP/IP no habilitado

Diagnósticos:

3.1. Se especificó el prefijo “tcp:” en el string de conexión, pero TCP/IP no está habilitado. Para solucionar esto, quitar el prefijo o habilitar TCP/IP.

3.2. Se usa el proveedor OLEDB, luego se conecta a la instancia por omisión usando “.” o “(local)”. Para solucionar esto, especificar como servidor “nombremáquina”.

CASO 4: Solamente NP habilitado

Diagnósticos:

4.1. Se especificó el prefijo “tcp:” en el string de conexión, pero TCP/IP no está habilitado. Para solucionar esto, quitar el prefijo o habilitar TCP/IP.

4.2. Se usa el proveedor OLEDB, luego se conecta a la instancia por omisión usando “.” o “(local)”. Para solucionar esto, especificar como servidor “nombremáquina”.

CASO 5: Solamente TCP/IP habilitado

Diagnósticos:

5.1. Se especificó el prefijo “np:” en el string de conexión, y NP no está habilitado. Para solucionar esto, eliminar el prefijo o habilitar NP.

CASO 6: Solamente SM está habilitado

CASO 7: Todos los protocolos están habilitados

En los Casos 6 y 7 todas las conexiones deberán ser exitosas, exceptuando algunos casos especiales que mencionaremos a continuación.

Caso especial 1: localhost

Windows 2000 y Windows XP no reconocen “localhost” como un nombre representativo de máquina en NP. En otras palabras, no se puede conectar a una instancia por omisión a través del pipe explícito file:///pipe/sql/query

Por ejemplo, el string de conexión es algo como:

"Data Source = file:///pipe/sql/query; Integrated Security = SSPI"

-o-

osql /S\\localhost\pipe\sql\query /E

Caso especial 2: Conexión a instancia local nombrada

Si no se puede identificar la causa de una conexión fallida cuando se usa MDAC para conectarse a una instancia local con nombre, hay otras dos razones posibles:

2.1. La aplicación ejecuta bajo una cuenta que no tiene permisos en la Registry de Windows donde el cliente MDAC lee. Dicha entrada es:

HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\instancia\MSSQLServer

2.2. El servicio SQL Browser no está iniciado o habilitado. Intentar:

net start sqlbrowser

Caso especial 3: Conexión remota

Cuando la conexión a un servidor remoto falla y se observa algunos de los mensajes de error de más arriba, primero hay que revisar si en el servidor remoto están habilitados NP o TCP/IP, y si el servicio SQL Browser está habilitado e iniciado.

Caso especial 4: Servidor especificado en blanco

Si se usa el driver ODBC y se deja en blanco el nombre del servidor al conectarse a una instancia local, la conexión puede fallar. Para solucionarlo, especificar el nombre del servidor cada vez que se haga una conexión. El error usualmente es:

[Microsoft][ODBC SQL Server Driver]Neither DSN nor SERVER keyword supplied

Caso especial 5: "." o "(local)"

Si se usa MDAC OLEDB, no se puede conectar a una instancia local por omisión, usando “.” o “(local)” cuando TCP/IP está inhabilitado. Para solucionar esto, usar el nombre de máquina al especificar el servidor en el string de conexión.

02 marzo, 2010

Una buena lista de herramientas gratuitas

En el blog de Mladen Prajdić (de Eslovenia, pero afortunadamente el blog está en inglés) encontré esta lista muy completa de herramientas gratuitas para usar con SQL Server:

Free SQL Server tools that might make your life a little easier
http://weblogs.sqlteam.com/mladenp/archive/2007/11/20/Free-SQL-Server-tools-that-might-make-your-life-a.aspx