Elección de un origen de datos o un controlador

El origen de datos o el controlador que usa una aplicación a veces se codifican de forma rígida en la aplicación. Por ejemplo, una aplicación personalizada escrita por un departamento MIS para transferir datos de un origen de datos a otro contendrá los nombres de esos orígenes de datos; la aplicación simplemente no funcionaría con ningún otro origen de datos. Otro ejemplo es una aplicación vertical, como una que se usa para la entrada del pedido. Esta aplicación siempre usa el mismo origen de datos, que tiene un esquema predefinido conocido por la aplicación.

Otras aplicaciones seleccionan el origen de datos o el controlador en tiempo de ejecución. Normalmente, se trata de aplicaciones genéricas que realizan consultas ad hoc, como una hoja de cálculo que usa ODBC para importar datos. Estas aplicaciones suelen enumerar los orígenes de datos o controladores disponibles y permiten a los usuarios elegir los con los que quieren trabajar. Si una aplicación genérica muestra orígenes de datos, controladores o ambos con frecuencia depende de si la aplicación usa controladores basados en DBMS o basados en archivos.

Normalmente, los controladores basados en DBMS requieren un conjunto complejo de información de conexión, como la dirección de red, el protocolo de red, el nombre de la base de datos, etc. El propósito de un origen de datos es ocultar toda esta información. Por lo tanto, el paradigma del origen de datos se presta para su uso con controladores basados en DBMS. Una aplicación puede mostrar una lista de orígenes de datos al usuario de una de estas dos maneras. Puede llamar a SQLDriverConnect con la palabra clave DSN (Nombre del origen de datos) y sin ningún valor asociado; El Administrador de controladores mostrará una lista de nombres de origen de datos. Si la aplicación quiere controlar la apariencia de la lista, llama a SQLDataSources para recuperar una lista de orígenes de datos disponibles y construye su propio cuadro de diálogo. El gestor de controladores implementa esta función y se puede llamar antes de que se carguen los controladores. A continuación, la aplicación llama a una función de conexión y la pasa el nombre del origen de datos elegido.

Si no se especifica un origen de datos, se usa el origen de datos predeterminado indicado por la información del sistema. (Para obtener más información, vea Subclave predeterminado). Si se llama a SQLConnect mediante un argumento ServerName que no se encuentra, es un puntero nulo o es "DEFAULT", el Administrador de controladores se conecta al origen de datos predeterminado. El origen de datos predeterminado también se usa si la cadena de conexión que se usa en una llamada a SQLDriverConnect o SQLBrowseConnect contiene la palabra clave DSN establecida en "DEFAULT" o si no se encuentra el origen de datos especificado. Además, el origen de datos predeterminado se usa si la cadena de conexión que se usa en una llamada a SQLDriverConnect no contiene la palabra clave DSN .

Con los controladores basados en archivos, es posible usar un paradigma de archivo. Para los datos almacenados en el equipo local, los usuarios suelen saber que sus datos están en un archivo determinado, como Employee.dbf. En lugar de seleccionar un origen de datos desconocido, es más fácil que estos usuarios seleccionen el archivo que conocen. Para implementar esto, la aplicación llama primero a SQLDrivers. El administrador de controladores implementa esta función y se puede llamar antes de que se carguen los controladores. SQLDrivers devuelve una lista de controladores disponibles; también devuelve valores para las palabras clave FileUsage y FileExtns . La palabra clave FileUsage explica si los controladores basados en archivos tratan los archivos como tablas, como Xbase o como bases de datos, como microsoft Access. La palabra clave FileExtns enumera las extensiones de nombre de archivo que reconoce el controlador, como .dbf para un controlador Xbase. Con esta información, la aplicación construye un cuadro de diálogo a través del cual el usuario elige un archivo. En función de la extensión del archivo elegido, la aplicación se conecta al controlador llamando a SQLDriverConnect con la palabra clave DRIVER .

No hay nada que impedir que una aplicación use un origen de datos con un controlador basado en archivos o llame a SQLDriverConnect con la palabra clave DRIVER para conectarse a un controlador basado en DBMS. Estos son varios usos comunes de la palabra clave DRIVER para controladores basados en DBMS:

• No se crean orígenes de datos. Por ejemplo, una aplicación personalizada podría usar un controlador y una base de datos concretos. Si el nombre del controlador y toda la información necesaria para conectarse a la base de datos está codificada de forma rígida en la aplicación, los usuarios no tienen que crear un origen de datos en su equipo para ejecutar la aplicación. Todo lo que deben hacer es instalar la aplicación y el controlador.

  Una desventaja de este método es que la aplicación debe volver a compilarse y redistribuirse si cambia la información de conexión. Si un nombre de origen de datos está codificado de forma rígida en la aplicación en lugar de completar la información de conexión, cada usuario solo debe cambiar la información del origen de datos.

• Acceso a un DBMS determinado una sola vez. Por ejemplo, una hoja de cálculo que recupera datos mediante una llamada a funciones ODBC podría contener la palabra clave DRIVER para identificar un controlador determinado. Dado que el nombre del controlador es significativo para los usuarios que tienen ese controlador, la hoja de cálculo podría pasarse entre esos usuarios. Si la hoja de cálculo contenía un nombre de origen de datos, cada usuario tendría que crear el mismo origen de datos para usar la hoja de cálculo.

• Examinar el sistema para identificar todas las bases de datos accesibles a un controlador específico. Para obtener más información, consulte Conexión con SQLBrowseConnect, más adelante en esta sección.