Cómo optimizar Microsoft Access cuando se usan orígenes de datos ODBC

Nota

Office 365 ProPlus pasa a llamarse Microsoft 365 Apps para empresas. Para obtener más información sobre este cambio, lea esta publicación de blog.

Avanzado: requiere capacidades multiusuario, interoperabilidad y Codificación experta.

Este artículo solo se aplica a una base de datos de Microsoft Access (. mdb o. accdb).

Resumen

En este artículo se describen varias sugerencias para mejorar el rendimiento al tener acceso a datos de un origen de datos ODBC.

Más información

Use las siguientes sugerencias para mejorar el rendimiento con orígenes de datos ODBC:

  • Restringir la cantidad de datos que se solicitan desde el servidor. No pida más datos de los que necesita. Use consultas para seleccionar solo los campos y las filas que necesita.

  • Use solo la funcionalidad que necesite. Las instantáneas son menos eficaces que los conjuntos de registros dinámicos y no se pueden actualizar. Sin embargo, las instantáneas pueden ser más rápidas, especialmente para conjuntos de registros pequeños sin campos memo u objeto OLE.

  • Cree tablas vinculadas (adjuntas) a los datos del servidor de acceso. Evite el acceso al servidor "directo" (es decir, no abra bases de datos remotas y ejecute consultas en ellas). En su lugar, cree tablas adjuntas o cree consultas de paso a través.

  • Diseñe de manera inteligente cuadros de lista y cuadros combinados. En un formulario, cada cuadro de lista, cuadro combinado, subformulario y control que contiene un total requiere una consulta independiente. Con datos locales, el rendimiento puede ser adecuado. Sin embargo, en el caso de los datos remotos, pueden producirse retrasos largos al abrir un formulario porque cada consulta debe enviarse al servidor y debe devolverse una respuesta antes de que se pueda abrir el formulario.

  • Evite cuadros combinados de gran tamaño. Si se incluye un cuadro combinado con cientos o incluso miles de opciones basadas en una tabla local, se puede producir un tiempo de respuesta aceptable, especialmente si se define un índice apropiado en la tabla local. Sin embargo, en una tabla remota, un cuadro combinado de este tipo genera un rendimiento bajo porque purga los recursos del servidor y de la red a medida que recupera los datos para rellenar la lista. Es mejor limitar el número de filas que se devuelven al cuadro combinado cuando se trabaja con datos remotos. También puede dividir los datos en cuadros combinados más pequeños (teniendo en cuenta la sugerencia anterior).

  • Use el comando find sólo en conjuntos de registros más pequeños. El motor de base de datos de Microsoft Jet optimiza el comando Buscar para que funcione correctamente con conjuntos de registros locales de casi cualquier tamaño y con conjuntos de registros remotos de tamaño razonable. Sin embargo, cuando tiene grandes conjuntos de registros remotos (miles de registros o más), debe crear un filtro o una consulta y también debe tener cuidado de usar restricciones que el servidor puede procesar.

  • Asegúrese de que las consultas se envían al servidor para su procesamiento. El factor más importante en el rendimiento de las consultas con datos remotos es asegurarse de que el servidor ejecuta la mayor parte posible de la consulta. El motor de base de datos Microsoft Jet intenta enviar toda la consulta a su servidor, pero evalúa localmente todas las cláusulas de consulta y expresiones que no son compatibles con los servidores o con un servidor concreto. La funcionalidad que no admiten los servidores en general incluye lo siguiente:

  • Operaciones que no se pueden expresar en una única instrucción SQL. Esta situación puede producirse cuando se usa una consulta como entrada a otra consulta o cuando la cláusula FROM de la consulta contiene una consulta de totales o una consulta DISTINCt. A menudo, puede reorganizar las consultas para calcular totales después de todas las demás operaciones.

    • Operaciones que son extensiones específicas del motor de base de datos de Microsoft Jet a SQL, como consultas de referencias cruzadas, consultas principales e informes con varios niveles de agrupamiento y totales. Tenga en cuenta que se pueden enviar consultas de referencias cruzadas sencillas a los servidores.
    • Expresiones que contienen operadores o funciones específicas de Microsoft Access. Las funciones financieras y los agregados estadísticos de Microsoft Access no tienen equivalentes en el servidor.
    • Funciones definidas por el usuario de Visual Basic para aplicaciones que toman columnas remotas como argumentos. Estas funciones no existen en el servidor, pero deben procesarse los datos de las columnas remotas. Sin embargo, si una función definida por el usuario devuelve un valor único y no hace referencia a una columna remota, la función se evalúa localmente y su valor se envía al servidor para su procesamiento.
    • Mezclar tipos de datos de texto y numéricos en operadores o en resultados de consulta de Unión. La mayoría de los servidores carecen del leniency de tipo de datos de Microsoft Access. Debido a esto, use las funciones de conversión explícitas cuando corresponda.
    • Combinaciones heterogéneas entre tablas locales y tablas remotas, o entre tablas remotas en diferentes orígenes de datos ODBC. Las combinaciones entre tablas locales pequeñas y tablas remotas grandes, donde la columna de combinación está indizada, pueden dar como resultado una combinación de índices remota. En una combinación de índice remota, se envía al servidor una consulta para cada fila de la tabla local, y sólo se devuelven las filas de Unión.
    • Expresiones que no son remotas o expresiones que no se pueden enviar de forma remota porque el servidor no puede evaluarlas. Las expresiones de salida que no son remotas (las de la cláusula SELECT) no fuerzan la evaluación local de la consulta a menos que se produzcan en una consulta de totales, una consulta DISTINCt o una consulta de Unión. Expresiones que no son remotas en otras cláusulas (WHERE, ORDER BY, GROUP BY, HAVING, etc.) fuerza que, al menos, una parte de la consulta se evalúe de forma local.
  • Los servidores difieren en algunas áreas de la funcionalidad admitida. Cuando se adjunta una tabla remota, el motor de base de datos de Microsoft Jet consulta al controlador ODBC sus funciones. Si el controlador y el servidor admiten la funcionalidad necesaria, el motor de base de datos Microsoft Jet envía la operación al servidor para su procesamiento. De lo contrario, el motor de base de datos de Microsoft Jet realiza la operación de forma local. Las áreas de compatibilidad diferente incluyen (entre otras) las siguientes:

    • Combinaciones externas. Tenga en cuenta que el motor de base de datos de Microsoft Jet no envía varias combinaciones externas a un servidor, aunque muchas combinaciones internas pueden acompañar a una sola Unión externa.
    • Funciones numéricas, de cadena y de fecha y hora, como log (), MID $ (), DatePart (), etc.
    • Funciones de conversión, como CInt (), CStr (), CVDate (), etc.