Elegir datos de un origen o el controlador

El origen de datos o el controlador que usa una aplicación a veces están codificados de forma rígida en la aplicación. Por ejemplo, una aplicación personalizada escrita por un departamento de MIS para transferir datos de un origen de datos a otro contendrá los nombres de esos orígenes de datos; la aplicación sencillamente 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 de pedidos. 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 que los usuarios elijan los que quieren usar. El hecho de que una aplicación genérica muestre orígenes de datos, controladores o ambos con frecuencia depende de si la aplicación usa controladores basados en DBMS o 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 los 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 de origen de datos) y ningún valor asociado; el Administrador de controladores mostrará una lista de nombres de origen de datos. Si la aplicación quiere controlar el aspecto 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 Administrador de controladores implementa esta función, a la que 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 le pasa el nombre del origen de datos elegido.

Si no se especifica ningún origen de datos, se usa el origen de datos predeterminado que indica la información del sistema. (Para obtener más información, consulte Subclave predeterminada.) Si se llama a SQLConnect mediante un argumento ServerName que no se puede encontrar, es un puntero nulo o es "DEFAULT", el Administrador de controladores se conecta al origen de datos predeterminado. También se usa el origen de datos predeterminado 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, se usa el origen de datos predeterminado 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, se puede usar un paradigma de archivo. En el caso de 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 implementarlo, la aplicación llama primero a SQLDrivers. El Administrador de controladores implementa esta función, a la que 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, igual que Xbase, o como bases de datos, igual que 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 selecciona un archivo. En función de la extensión del archivo seleccionado, la aplicación se conecta al controlador mediante una llamada a SQLDriverConnect con la palabra clave DRIVER.

No hay nada que impida 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 los controladores basados en DBMS:

• Sin crear 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án codificados 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. Solo tienen que instalar la aplicación y el controlador.

  Un inconveniente 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 debe cambiar únicamente 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 de 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 lo tienen, 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 de todas las bases de datos accesibles para un controlador determinado. Para obtener más información, consulte Conexión con SQLBrowseConnect, más adelante en esta sección.