¿Cómo se comunica Access con las fuentes de datos ODBC? Parte 5

Filtrar el conjunto de registros

En la parte 5 de nuestra serie, aprenderemos cómo Microsoft Access maneja los filtros implementados y los integra en las consultas ODBC. En el artículo anterior, vimos cómo Access formulará el SELECT declaraciones en los comandos SQL de ODBC. También vimos en el artículo anterior cómo Access intentará actualizar una fila aplicando un WHERE cláusula basada en la clave y, si corresponde, en la versión de fila. Sin embargo, necesitamos saber cómo manejará Access los filtros que se proporcionan a las consultas de Access y cómo los traducirá en la capa ODBC. Hay diferentes enfoques que Access puede usar dependiendo de cómo se formulen las consultas de Access y aprenderá cómo predecir cómo Access traducirá una consulta de Access en una consulta ODBC para diferentes predicados de filtro dados.

Independientemente de cómo aplique realmente el filtro, ya sea de forma interactiva a través de los comandos de la cinta de opciones de la hoja de datos o del formulario, o haciendo clic en el menú derecho, o programáticamente usando VBA o ejecutando consultas guardadas, Access emitirá una consulta ODBC SQL correspondiente para realizar el filtrado. En general, Access intentará filtrar de forma remota tanto como sea posible. Sin embargo, no le dirá si no puede hacerlo. En cambio, si Access no puede expresar el filtro usando la sintaxis SQL de ODBC, intentará realizar el filtrado descargando todo el contenido de la tabla y evaluando la condición localmente. Eso puede explicar por qué en algún momento puede encontrarse con una consulta que se ejecuta rápidamente pero con un pequeño cambio, se ralentiza a paso de tortuga. Con suerte, esta sección lo ayudará a comprender cuándo puede suceder esto y cómo manejarlo para que pueda ayudar a Acceder de forma remota tanto como sea posible a las fuentes de datos para aplicar el filtro.

Para este artículo, utilizaremos consultas guardadas, pero la información que se analiza aquí aún debería aplicarse a otros métodos de aplicación de filtros.

Filtros estáticos

Comenzaremos de manera fácil y crearemos una consulta guardada con un filtro codificado.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName="Boston";

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" = 'Boston' ) 

Filtros parametrizados simples

Cambiemos el SQL para usar un parámetro en su lugar:

PARAMETERS SelectedCityName Text ( 255 );
SELECT 
  c.CityID
 ,c.CityName
 ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName=[SelectedCityName];

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" =  ? ) 

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName=[Forms]![frmSomeForm]![txtSomeText];

Eso también funciona para la función VBA. Podemos agregar una nueva función VBA:

Public Function GetSelectedCity() As String
    GetSelectedCity = "Boston"
End Function

WHERE c.CityName=GetSelectedCity();

Sin embargo, hay un escenario más común que los desarrolladores de Access suelen configurar y que es la creación de SQL dinámico con código VBA, generalmente mediante la concatenación de una cadena y luego la ejecución de la cadena concatenada. Usemos el siguiente código VBA:

Public Sub GetSelectedCities()
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim fld As DAO.Field
    
    Dim SelectedCity As String
    Dim SQLStatement As String
    
    SelectedCity = InputBox("Enter a city name")
    SQLStatement = _
        "SELECT c.CityID, c.CityName, c.StateProvinceID " & _
        "FROM Cities AS c " & _
        "WHERE c.CityName = '" & SelectedCity & "';"
    
    Set db = CurrentDb
    Set rs = db.OpenRecordset(SQLStatement)
    Do Until rs.EOF
        For Each fld In rs.Fields
            Debug.Print fld.Value;
        Next
        Debug.Print
        rs.MoveNext
    Loop
End Sub

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" = 'Boston' ) 

Por ese motivo, las consultas parametrizadas de Access en fuentes ODBC pueden ser preferibles a SQL dinámico. Debido a que Access tratará los controles de referencias en un formulario o funciones de VBA que no requieren referencias de columna como parámetros, no necesita parámetros explícitos en sus fuentes de registros o fuentes de filas. Sin embargo, si usa VBA para ejecutar SQL, generalmente es mejor usar ADO, que también tiene un soporte mucho mejor para la parametrización. En el caso de crear un origen de registros dinámico o un origen de filas, usar un control oculto en el formulario/informe puede ser una forma fácil de parametrizar la consulta. Sin embargo, si la consulta es marcadamente diferente, construir el SQL dinámico en VBA y asignarlo a la propiedad recordsource/rowsource efectivamente fuerza una recompilación completa y, por lo tanto, evita el uso de planes de ejecución incorrectos que no funcionarán bien para el conjunto actual de entradas. Puede encontrar recomendaciones en el artículo sobre WITH RECOMPILE de SQL Server. útil para decidir si forzar una recompilación o usar una consulta parametrizada.

Uso de funciones en el filtrado de SQL

En la sección anterior, vimos que una declaración SQL que contenía una función VBA se parametrizó para que Access pudiera ejecutar la función VBA y usar la salida como entrada para la consulta parametrizada. Sin embargo, no todas las funciones integradas se comportan de esta manera. Usemos UCase() como ejemplo para filtrar la consulta. Además, aplicaremos la función en una columna.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE UCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ({fn ucase("CityName" )}= 'BOSTON' )

Si luego creamos una función VBA personalizada que emula UCase() función:

Public Function MyUCase(InputValue As Variant) As String
    MyUCase = UCase(InputValue)
End Function

WHERE MyUCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT 
   "CityName"
  ,"c"."CityID" 
FROM "Application"."Cities" "c" 

Aunque usamos UCase() en este ejemplo, podemos ver claramente que, por lo general, es mejor enviar de forma remota la mayor cantidad de trabajo posible a la fuente de datos. Pero, ¿qué sucede si tenemos una función VBA compleja que no se puede reescribir en el dialecto SQL nativo de la fuente de datos? Aunque creo que este escenario es bastante raro, vale la pena considerarlo. Supongamos que podemos agregar un filtro para acotar el conjunto de ciudades devueltas.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName LIKE "Bos*"
  AND MyUCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT 
   "CityName"
  ,"c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" LIKE 'Bos%' ) 

Esto nos dice que si nos enfrentamos al escenario indeseable en el que no podemos refactorizar fácilmente una función VBA compleja de una consulta, aún podemos mitigar los efectos negativos agregando filtros que se pueden controlar de forma remota para reducir el conjunto inicial de registros para que funcione Access.

Una nota sobre sargabilidad

En los ejemplos anteriores, aplicamos una función escalar en una columna. Eso tiene el potencial de hacer que la consulta sea "no sargable", lo que significa que el motor de la base de datos no puede optimizar la consulta usando el índice para buscar y encontrar coincidencias. La parte "sarg" de la palabra "sargability" se refiere a "Argumento de búsqueda". Supongamos que tenemos el índice definido en la fuente de datos de la tabla:

CREATE INDEX IX_Cities_CityName
ON Application.Cities (CityName);

CREATE INDEX IX_Cities_Boston_Uppercase
ON Application.Cities (CityName)
WHERE UCASE(CityName) = 'BOSTON';

Independientemente del motor de base de datos con el que esté trabajando, siempre es preferible diseñar y utilizar consultas sargable siempre que sea posible para evitar problemas de rendimiento. Las consultas cruciales deben tener índices de cobertura para proporcionar el mejor rendimiento. Lo animo a que estudie más sobre la sargabilidad y los índices de cobertura para ayudarlo a evitar diseñar consultas que de hecho no son sargables.

Conclusiones

Revisamos cómo maneja Access la aplicación de filtros de Access SQL en las consultas ODBC. También exploramos diferentes casos en los que Access convertirá diferentes tipos de referencias en un parámetro, lo que permitirá a Access realizar la evaluación fuera de la capa ODBC y pasarlos como entradas a la declaración ODBC preparada. También analizamos lo que sucede cuando no se puede parametrizar, generalmente debido a que contiene referencias de columna como entradas. Eso puede tener consecuencias en el rendimiento durante una migración al servidor SQL.

Para ciertas funciones, Access puede convertir la expresión para usar funciones escalares ODBC en su lugar, lo que permite que Access controle de forma remota la expresión a la fuente de datos ODBC. Una ramificación de esto es que si la implementación de la función escalar es diferente, puede hacer que la consulta se comporte de manera diferente o puede funcionar más rápido o más lento. Vimos cómo una función de VBA, incluso una simple que envuelve una función escalar que de otro modo se podría controlar de forma remota, puede frustrar los esfuerzos para controlar de forma remota la expresión. También aprendemos que si tenemos una situación en la que no podemos refactorizar una función VBA compleja de una consulta de Access/recordsource/rowsource, al menos podemos mitigar la costosa descarga agregando filtros adicionales en la consulta que se pueden controlar de forma remota para reducir la cantidad. de datos devueltos.

En el próximo artículo veremos cómo Access maneja las uniones.

¿Busca ayuda con Microsoft Access? Llame a nuestros expertos hoy al 773-809-5456 o envíenos un correo electrónico a [email protected].