Cómo optimizar Microsoft Access al usar 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 codificación experta, interoperabilidad y habilidades multiusuario.

Este artículo solo se refiere 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 desde un origen de datos ODBC.

Más información

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

  • Restrinja la cantidad de datos que solicita al servidor. No pida más datos de los que necesita. Use consultas para seleccionar solo los campos y filas que necesita.

  • Use solo la funcionalidad que necesita. Las instantáneas son menos eficaces que los conjuntos 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) para obtener acceso a los datos del servidor. 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 cuadros de lista y cuadros combinados con prudencia. En un formulario, cada cuadro de lista, cuadro combinado, subformulario y control que contiene un total requiere una consulta independiente. En función de los datos locales, el rendimiento puede ser adecuado. En los datos remotos, sin embargo, 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 grandes. Incluir un cuadro combinado con cientos, o incluso miles, de opciones basadas en una tabla local puede producir un tiempo de respuesta aceptable, especialmente si se define un índice adecuado en la tabla local. Sin embargo, en una tabla remota, este cuadro combinado produce un rendimiento lento porque drena los recursos de red y servidor a medida que captura datos para rellenar la lista. Es mejor limitar el número de filas devueltas 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 Buscar solo en conjuntos de registros más pequeños. El motor de base de datos de Microsoft Jet optimiza el comando Buscar para que funcione bien con conjuntos de registros locales de casi cualquier tamaño y con conjuntos de registros remotos de un tamaño razonable. Sin embargo, cuando tiene conjuntos de registros remotos grandes (miles de registros o más), debe crear un filtro o consulta y también 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 respecto a los datos remotos es garantizar que el servidor ejecute la mayor parte de la consulta posible. El motor de base de datos de Microsoft Jet intenta enviar toda la consulta al servidor, pero evalúa localmente las cláusulas y expresiones de consulta que generalmente no son compatibles con los servidores o el servidor en particular. La funcionalidad no admitida por los servidores en general incluye lo siguiente:

  • Operaciones que no se pueden expresar en una sola SQL instrucción. 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 Totals o una consulta DISTINCT. A menudo, puede reorganizar las consultas para calcular los totales después de todas las demás operaciones.

    • Operaciones que son extensiones específicas del motor de base de datos de Microsoft Jet para SQL, como consultas de tabla cruzada, consultas TOP e informes con varios niveles de agrupación y totales. Tenga en cuenta que las consultas de referencias cruzadas simples se pueden enviar a los servidores.
    • Expresiones que contienen funciones o operadores específicos de Microsoft Access. Las funciones financieras de Microsoft Access y los agregados estadísticos no tienen equivalentes de servidor.
    • Configuración definida por el Visual Basic para funciones de aplicación que toman columnas remotas como argumentos. Estas funciones no existen en el servidor, pero deben procesar datos de columnas remotas. Sin embargo, si una función definida por el usuario devuelve un único valor 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 numéricos y texto en operadores o salidas de consulta UNION. La mayoría de los servidores carecen de la indulgencia de tipo de datos de Microsoft Access. Debido a esto, use funciones de conversión explícitas cuando corresponda.
    • Combinaciones heterogéneos 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 grandes tablas remotas, donde se indiza la columna de combinación, pueden dar como resultado una combinación de índice remoto. En una combinación de índice remoto, se envía al servidor una consulta para cada fila de la tabla local y solo se devuelven las filas de unión.
    • Expresiones no remotas o expresiones que no se pueden enviar de forma remota, porque el servidor no las puede evaluar. Las expresiones de salida no remotas (las de la cláusula SELECT) no fuerzan la evaluación local de la consulta a menos que se produzcan en una consulta Totals, una consulta DISTINCT o una consulta UNION. Las expresiones no remotas de otras cláusulas (WHERE, ORDER BY, GROUP BY, HAVING, entre otras) fuerzan al menos una parte de la consulta a evaluarse localmente.
  • Los servidores difieren en algunas áreas de funcionalidad admitida. Al adjuntar una tabla remota, el motor de base de datos de Microsoft Jet consulta al controlador ODBC para sus capacidades. Si el controlador y el servidor admiten la funcionalidad necesaria, el motor de base de datos de Microsoft Jet envía la operación al servidor para su procesamiento. Si no es así, el motor de base de datos de Microsoft Jet realiza la operación localmente. Entre las áreas de compatibilidad diferentes se incluyen (pero no se limitan a) 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 una única combinación externa.
    • Funciones numéricas, de cadena y de fecha y hora, como Log(), Mid$(), DatePart(), y así sucesivamente.
    • Funciones de conversión, como CInt(), CStr(), CVDate(), y así sucesivamente.