Analicemos cada campo: el primero, Name, nos pide el nombre del origen de datos que vamos a crear, y que será el utilizado por la aplicación. Se puede poner cualquier nombre, sin espacios en blanco ni símbolos, sólo letras y números, como en el ejemplo: pruebas.

Este nombre no tiene por qué ser el mismo que el de la base de datos que hay vinculada a él. Al facilitar este nombre al IDC, el ODBC se encargará de que la aplicación "entienda" lo que dice la base de datos.

El siguiente campo, Description es un breve comentario del origen de datos, si te es necesario, sino, puedes dejarlo vacio.

El último campo de esta pantalla es Server, y se refiere al nombre del servidor de bases de datos. Si no eres el administrador del servidor de bases de datos, puede que no sepas qué poner. Un servidor Windows NT con SQL Server se comporta en algunos casos como si se tratase de dos máquinas distintas, aunque en realidad es una misma. Dependiendo de a qué servicio queremos llegar se usa un nombre u otro, aunque podría ser el mismo en ambos casos, pero no se escriben de la misma forma.

Las máquinas con sistema Windows NT o 95/98 se suelen agrupar en lo que se denominan grupos de trabajo, que son los que te aparecen en el icono Entorno de red del escritorio. La forma de referenciar una máquina de tu mismo grupo es mediante su nombre en el grupo. Supongamos que el nombre de nuestro servidor en internet es el siguiente: Mi_server.mi_empresa.mi_pais y que tiene asignada la dirección IP 255.255.255.255

Normalmente, esta máquina aparecerá en el grupo como MI_server y si te quieres conectar a su servicio de impresora, por ejemplo, usarías la dirección: \\Mi_server\impresora.

Habitualmente, los administradores de servidores asignan a los servidores de bases de datos el mismo nombre que tiene la máquina en la que residen, aunque puede ocurrir, por razones especiales, que no sea así. SQL Server, por defecto, adopta el nombre de la máquina en el grupo cuando se instala, es decir, MI_server, pero se podría haber utilizado otro. De ahí podría surgir la impresión de que se trata de dos máquinas diferentes. Fíjate que en cualquier caso, NO se utilizan las dos barras inclinadas delante del nombre.

Y una cosa más: en los sistemas NT, no olvidar que el usuario definido para acceder desde internet, exista, ademas de como usuario de NT, como usuario de la DB, y tenga los permisos necesarios para llegar y operar en ella. Si SQL Server se ha instalado con la Trusted security, el usuario y palabra de paso para el servidor NT y para SQL Server tienen que ser iguales. Es como abrir dos puertas con la misma llave.

Una vez cumplimentados los tres campos, pulsa el botón Siguiente

Evidentemente, la primera de las dos opciones, autenticación NT usando el login entrado en la conexión de red, no es lógica para una aplicación de internet, en que el cliente utlizará unos parámetros de conexión a su propia red o a ninguna. Esta podría servir en caso de que la aplicación se utilice en una intranet, y que no todos los usuarios tuviesen los mismos permisos. Por lo tanto marcaremos la segunda opción: Autenticación SQL Server usando un login y password dados por el usuario; y cuando dice "...dados por el usuario" no se refiere a que el cliente tenga que hacer esto cuando se conecte, sino a que el usuario y password los tenemos que proporcionar ahora, en los dos últimos campos del formulario, en este caso el usuario es web y como palabra de paso en este caso no pondremos ninguna (que también es una forma de password).

Tanto en aplicaciones programadas con el IDC como con ASP, los usuarios y passwords utilizados, no "viajan" con la información. Recuerda que son programas que se ejecutan en el propio servidor, y se activan a petición del IIS, que a su vez , atiende una llamada http que le hace el cliente al servidor web con un usuario anónimo, y después de procesarla convenientemente, y de resolver internamente las conexiones con la DB que sean necesarias, al cliente le devolverán html estándar y transparente. Con esto se evita el tener que facilitar a los clientes claves que podrían ser capturadas en la red indebidamente.

Este usuario anónimo utilizado por defecto en el IIS, normalmente sólo tiene permisos de lectura en áreas muy concretas del servidor NT. A las aplicaciones internet, habitualmente, no se les da nunca permisos para borrar nada, lo máximo que suelen poder hacer, es insertar registros en las tablas, y ocasionalmente, alguna pequeña modificación de datos, como puedan ser domicilios, o teléfonos. Si el cliente desea ser borrado de la base de datos, normalmente lo solicitará al administrador de la DB, que procederá desde su aplicación en la intranet.

No se debe confundir este tipo de autenticaciones con las que se hacen desde una página web, que puede pedirnos un nombre de usuario (login) y una clave (password). En estos casos se trata de directorios protegidos en el propio servidor web, y concretamente con el IIS, es tan sencillo como asignar el directorio en cuestión a un usuario NT existente. Y es buena idea, puesto que en este caso la clave si viaja, que estos usuarios sólo tengan permisos de lectura, y si la información que se va a acceder es confidencial, se deberán instalar sistemas de encriptación de los que soportan la mayoría de navegadores modernos, o utilizar sistemas más sofisticados a base de certificados electrónicos.

Cuando se instala alguna página en uno de estos directorios protegidos, un problema muy habitual que suelen tener los clientes que utilizan el Internet Explorer como navegador, consiste en que sistemáticamente reciben un mensaje de error del servidor, denegando el acceso. Esto es debido a que por defecto, el IE siempre intenta conectarse a los servidores en modo intranet, y por tanto envia automáticamente al servidor web el usuario y clave de conexión a red local, que evidentemente, no son los que espera el servidor internet, provocando el error de acceso.

La solución consiste en configurar, en el cliente, correctamente el IE para que se conecte en modo internet, cosa que no todo el mundo sabe hacer, o bien cerrar la sesión de red local y abrir una nueva sin conexión, con lo que el IE no podrá enviar nada, y podremos introducir las claves correctas cuando el servidor internet las demande. Esto no ocurre con Netscape, que siempre inicia la conexión en modo internet (de hecho no tiene otra).

Y continuando con nuestro ODBC, el siguiente paso será pulsar el botón Client configuration.

Para resolver este problema, SQL Server viene provisto de un cliente especial que se encargará de hacer las conversiones de nombre necesarias entre un sistema y otro.

En la primera de las tres vistas que tiene este paso, DB Library, se configura si se aplicará alguna conversión de caracteres o no. La conversión de ANSI a OEM, sirve para cambiar el juego por defecto de SQL Server. Como ya debes de saber, SQL Server utiliza el juego de caracteres ANSI para almacenar los datos. Este juego de caracteres es distinto al OEM utilizado por los sistemas Windows, de modo que si escribimos con nuestra aplicación internet, por ejemplo una "Ñ" o una letra acentuada en la tabla, sin aplicar esta conversión, será guardada en equivalente ANSI. Si se pide ese registro a SQL Server desde su consola de control, o desde algun cliente, como IWSql, que son ANSI, no la veremos tal cual, sino un caracter extraño. El mismo registro, solicitado mediante la misma aplicación que lo escribió se verá correctamente, y lo mismo ocurre con las aplicaciones locales desarrolladas para sistemas Windows, como Access 97. Como no es habitual explotar las tablas desde la consola o desde clientes SQL, es preferible dejar al servidor utilizar su juego por defecto. Si hay que cambiarlo, hay pensarlo ahora, ya que cuando existan registros en las tablas, si se cambia, será trabajoso aplicar la conversión a todos ellos.

Los tres siguientes campos se limitan a mostrarnos información de la libreria de red elegida: dónde está, cómo va a mostrar las fechas (que concide con lo definido en la configuración regional de la máquina) y el tamaño de la misma.

A continuación pulsar el botón Add/Modify para que aparezca la correspondiente línea en la ventana Current Entries

De la misma forma, si alguno de ellos cambia de nombre o de IP, sólo hay que seleccionar la línea correspondiente y pulsar de nuevo al botón Add/Modify para modificar lo que proceda.

Pulsar el botón Done para concluir la configuración del cliente SQL Server y pasar a la siguiente pantalla del ODBC.

Si habitualmente utilizamos el usuario web para las transacciones internet, lo normal será que tenga permisos en varias bases de datos, y por tanto habrá que definir en cada ODBC cual es la DB por defecto. Esto se hace marcando la casilla Change the dafault data base to y escogiendo a continuación de la lista que hay debajo la que proceda.

Lo que aparece en esa lista sí son nombres de bases de datos y no de orígenes de datos definidos para ODBC, aunque en este caso coincidan. En la imagen puedes ver cómo marcar el resto. Fíjate que, en general, se suele dejar a SQL Server utilizar los valores ANSI para casi todo. Procura crear los ODBC siempre igual, te evitarás problemas inesperados, y dudas del tipo "..¿dónde estará fallando..?". Recuerda que SQL Server trabaja internamente con el lenguaje SQL ANSI que incluye un gran número de funciones de todo tipo y de system procedures, o procedimientos de sistema, auténticos programas escritos en SQL, y con los que se administra el servirdor, que trabajan mal con datos que no sean compatibles ANSI. Siempre que haya que hacer una traslación que sea fuera de las tablas.

Los siguientes son algo parecido a los que hay en la primera pantalla del paso 4: el primero permite al ODBC elegir el método de traslación; el segundo indica que no se debe utilizar ningún método de traslación; el tercero fuerza la conversión del juego de caracteres, pero en lugar de ANSI a OEM que se hacía en el paso 4, aquí es de OEM a ANSI; el cuarto es para utilizar un conversor propio del ODBC, que hay de definir, y no el de SQL Server.

Hay una gran diferencia entre estos sistemas de traslación y los del paso 4: Aquí la traslación se realiza después de extraer el dato de la tabla y antes de presentarlo en pantalla, es decir, que son traslaciones sólo a efectos de visualización y no afectan a los datos. En el paso 4 la traslación se hace antes de guardar el dato en la tabla, y sí afectan a los datos.

Y por fin el último control sirve para definir cómo se presentarán las fechas, números y monedas en pantalla: si en formato ANSI o según lo especificado en la configuración regional de la máquina

Pulsar el botón Siguiente después de haber marcado lo que proceda.

Pulsar el botón Finalizar para pasar al último paso.

Si el origen de datos no funciona desde aquí no funcionará desde ninguna parte. Si la aplicación da problemas, y este test funciona correctamente, el fallo hay que buscarlo en la aplicación. Si un origen de datos que funcionaba deja de hacerlo, el problema puede estar en la red, o en el SQL Server. Revisar si el usuario todavia es válido para esa DB, y si lo es, si se mantienen los permisos que tenía. Si todo es correcto, pero sigue sin funcionar, lo mejor es borrarlo y crear uno nuevo. Lo único que se prueba desde aquí es si el ODBC puede llegar a la DB con el usuario definido en modo lectura, no si hay datos en la DB, o si se puede escribir en ella.