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

Avanzado: requiere conocimientos avanzados de código, interoperabilidad y multiusuario.

Este artículo se aplica únicamente a las bases de datos de Microsoft Access (.accdb o .mdb).

Para obtener una versión de este artículo para Microsoft Access 2000, vea
209091.

Para obtener una versión de este artículo para Microsoft Access 97, vea
113551.

Resumen

Este artículo describe varias sugerencias para mejorar el rendimiento al tener acceso a los datos de un origen de datos ODBC.

Más información

Utilice las sugerencias siguientes para mejorar el rendimiento de los orígenes de datos ODBC:

  • Restrinja la cantidad de datos que solicita del servidor. No pida más datos de los que necesite. Use consultas para seleccionar sólo los campos y filas que necesite.

  • Utilice sólo la funcionalidad que necesite. Las instantáneas son menos eficaces que los conjuntos de registros dinámicos y no son actualizables. Sin embargo, las instantáneas pueden ser más rápidas, particularmente con 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 "directo" al servidor (es decir, no abra las bases de datos remotas y ejecute consultas con ellas). En su lugar, cree tablas adjuntas o cree consultas de paso a través.

  • Diseñe exhaustivamente los cuadros de lista y los 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, con datos remotos puede haber retrasos largos al abrir un formulario porque cada consulta se debe enviar al servidor y se debe devolver una respuesta antes de que se pueda abrir el formulario.

  • Evite cuadros combinados grandes. Al incluir un cuadro combinado con centenares o incluso miles de opciones basadas en una tabla local, se puede producir un tiempo de respuesta aceptable, sobre todo si define un índice adecuado en la tabla local. Con una tabla remota, sin embargo, este tipo de cuadro combinado produce un rendimiento bajo porque agota los recursos de la red y del servidor cuando obtiene los datos para rellenar la lista. Es mejor limitar el número de filas que devuelve el cuadro combinado cuando trabaja con datos remotos. También puede dividir los datos en cuadros combinados más pequeños (teniendo presente la sugerencia anterior).

  • Utilice el comando Find sólo en conjuntos de registros más pequeños. El motor de base de datos Microsoft Jet optimiza el comando Find para funcionar 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 tenga conjuntos de registros remotos grandes (de miles de registros o más), debería crear en su lugar un filtro o una consulta además de tener la precaución de utilizar restricciones que el servidor pueda procesar.

  • Realice consultas seguras que se envían al servidor para procesarse. El factor más importante en el rendimiento de las consultas de 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 la consulta completa al servidor, pero evalúa localmente cualquier cláusula y expresiones de las consultas que suelen no admitirse en los servidores o en un servidor determinado. La funcionalidad que no admiten los servidores en general incluye la siguiente:

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

    • Operaciones que son extensiones a SQL específicas del motor de base de datos Microsoft Jet, como consultas de tabla de referencias cruzadas, consultas TOP e informes con varios niveles de agrupamiento y totales. Observe que las consultas de tablas de referencias cruzadas simples se pueden enviar a los servidores.

    • Expresiones que contienen operadores o funciones específicos de Microsoft Access. Las funciones financieras y los agregados estadísticos de Microsoft Access no tienen ningún equivalente de servidor.

    • Funciones de Visual Basic para Aplicaciones definidas por el usuario que aceptan columnas remotas como argumentos. Estas funciones no existen en el servidor, pero deben procesar los datos de columnas remotos. Sin embargo, si una función definida por el usuario devuelve un valor único y hace referencia a una columna remota, la función se evalúa localmente y su valor se envía al servidor para que lo procese.

    • Mezclar tipos de datos de texto y numéricos de operadores o resultados de las consultas UNION. La mayoría de los servidores no tienen la flexibilidad de tipos de datos de Microsoft Access. Debido a esto, utilice funciones de conversión explícita donde corresponda.

    • Combinaciones heterogéneas entre tablas locales y tablas remotas, o entre tablas remotas de orígenes de datos ODBC diferentes. Las combinaciones entre tablas locales pequeñas y tablas remotas grandes, donde la columna de combinación se indiza, pueden producir una combinación de índices remota. En una combinación de índices remota, se envía al servidor una consulta de cada fila de la tabla local y sólo se devuelven las filas de la combinación.

    • Expresiones que no pueden ser remotas, o expresiones que no se pueden enviar remotamente, porque el servidor no puede evaluarlas. Las expresiones de salida que no pueden ser remotas (las de la cláusula SELECT) no fuerzan la evaluación local de la consulta a menos que aparezcan en una consulta Totals, una consulta DISTINCT o una consulta UNION. Las expresiones que no pueden ser remotas en otras cláusulas ((WHERE, ORDER BY, GROUP BY, HAVING, etc.) hacen que al menos parte de la consulta se evalúe localmente.

  • Los servidores difieren en algunas áreas de la funcionalidad admitida. Al adjuntar una tabla remota, el motor de base de datos Microsoft Jet consulta sus capacidades en el controlador ODBC. Si el controlador y el servidor admiten la funcionalidad requerida, el motor de base de datos Microsoft Jet envía la operación al servidor para procesarla. Si no, el motor de base de datos Microsoft Jet realiza la operación localmente. Entre las áreas en las que la compatibilidad varía se encuentran las siguientes, entre otras:

    • Combinaciones externas. Observe que el motor de base de datos Microsoft Jet no envía varias combinaciones externas a un servidor, aunque muchas combinaciones internas pueden acompañar a una única combinació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.

¿Necesita más ayuda?

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Unirse a Microsoft Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×