Comment Access communique-t-il avec les sources de données ODBC ? Partie 5

Filtrer le jeu d'enregistrements

Dans la partie 5 de notre série, nous apprendrons comment Microsoft Access gère les filtres implémentés et les intègre dans les requêtes ODBC. Dans l'article précédent, nous avons vu comment Access va formuler le SELECT instructions dans les commandes SQL ODBC. Nous avons également vu dans l'article précédent comment Access va essayer de mettre à jour une ligne en appliquant un WHERE clause basée sur la clé et, le cas échéant, rowversion. Cependant, nous devons apprendre comment Access gérera les filtres fournis aux requêtes Access et les traduira dans la couche ODBC. Access peut utiliser différentes approches en fonction de la formulation des requêtes Access et vous apprendrez à prédire comment Access traduira une requête Access en une requête ODBC pour différents prédicats de filtre donnés.

Quelle que soit la manière dont vous appliquez réellement le filtre - que ce soit de manière interactive via les commandes du ruban du formulaire ou de la feuille de données ou les clics du menu droit, ou par programmation à l'aide de VBA ou en exécutant des requêtes enregistrées - Access émettra une requête SQL ODBC correspondante pour effectuer le filtrage. En général, Access essaiera de filtrer autant que possible à distance. Cependant, il ne vous dira pas s'il ne peut pas le faire. Au lieu de cela, si Access ne peut pas exprimer le filtre à l'aide de la syntaxe SQL ODBC, il tentera à la place d'effectuer lui-même le filtrage en téléchargeant l'intégralité du contenu de la table et en évaluant la condition localement. Cela peut expliquer pourquoi vous pouvez parfois rencontrer une requête qui s'exécute rapidement mais qui, avec un petit changement, ralentit jusqu'à l'exploration. Cette section, espérons-le, vous aidera à comprendre quand cela peut se produire et comment le gérer afin que vous puissiez aider à accéder à distance autant que possible aux sources de données pour appliquer le filtre.

Pour cet article, nous utiliserons des requêtes enregistrées, mais les informations présentées ici devraient toujours s'appliquer aux autres méthodes d'application de filtres.

Filtres statiques

Nous allons commencer facilement et créer une requête enregistrée avec un filtre codé en dur.

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' ) 

Filtres paramétrables simples

Modifions le SQL pour utiliser un paramètre à la place :

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];

Cela fonctionne également pour la fonction VBA. Nous pouvons ajouter une nouvelle fonction VBA :

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

WHERE c.CityName=GetSelectedCity();

Cependant, il existe un autre scénario courant que les développeurs Access configurent généralement et qui consiste à créer du SQL dynamique avec du code VBA, généralement en concaténant une chaîne, puis en exécutant la chaîne concaténée. Utilisons le code VBA suivant :

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' ) 

Pour cette raison, les requêtes paramétrées d'Access sur les sources ODBC peuvent être préférables au SQL dynamique. Étant donné qu'Access traitera les contrôles de référence sur un formulaire ou les fonctions VBA qui ne nécessitent pas de références de colonne comme des paramètres, vous n'avez pas besoin de paramètres explicites dans vos sources d'enregistrement ou de ligne. Cependant, si vous utilisez VBA pour exécuter SQL, il est généralement préférable d'utiliser ADO, qui offre également une bien meilleure prise en charge du paramétrage. Dans le cas de la création d'une source d'enregistrement dynamique ou d'une source de ligne, l'utilisation d'un contrôle masqué sur le formulaire/rapport peut être un moyen simple de paramétrer la requête. Cependant, si la requête est nettement différente, la construction du SQL dynamique dans VBA et son affectation à la propriété recordsource/rowsource force effectivement une recompilation complète et évite donc d'utiliser de mauvais plans d'exécution qui ne fonctionneront pas bien pour l'ensemble actuel d'entrées. Vous pouvez trouver des recommandations dans l'article traitant de WITH RECOMPILE de SQL Server utile pour décider s'il faut forcer une recompilation ou utiliser une requête paramétrée.

Utilisation des fonctions dans le filtrage SQL

Dans la section précédente, nous avons vu qu'une instruction SQL contenant une fonction VBA était paramétrée afin qu'Access puisse exécuter la fonction VBA et utiliser la sortie comme entrée de la requête paramétrée. Cependant, toutes les fonctions intégrées ne se comportent pas de cette façon. Utilisons UCase() comme exemple pour filtrer la requête. De plus, nous allons appliquer la fonction sur une colonne.

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 nous créons ensuite une fonction VBA personnalisée qui émule UCase() fonction :

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" 

Bien que nous ayons utilisé UCase() dans cet exemple, nous pouvons clairement voir qu'il est généralement préférable de déporter autant de travail que possible à la source de données. Mais que se passe-t-il si nous avons une fonction VBA complexe qui ne peut pas être réécrite dans le dialecte SQL natif de la source de données ? Bien que je pense que ce scénario est assez rare, il vaut la peine d'être considéré. Supposons que nous puissions ajouter un filtre pour restreindre l'ensemble des villes renvoyées.

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%' ) 

Cela nous indique que si nous sommes confrontés au scénario indésirable où nous ne pouvons pas facilement refactoriser une fonction VBA complexe à partir d'une requête, nous pouvons toujours atténuer les effets néfastes en ajoutant des filtres qui peuvent être distants pour réduire l'ensemble initial d'enregistrements avec lesquels Access doit travailler.

Une note sur la sargabilité

Dans les exemples précédents, nous avons appliqué une fonction scalaire sur une colonne. Cela a le potentiel de rendre la requête comme "non-sargable", ce qui signifie que le moteur de base de données est incapable d'optimiser la requête en utilisant l'index pour rechercher et trouver des correspondances. La partie "sarg" du mot "sargability" fait référence à "Search ARGument". Supposons que l'index soit défini au niveau de la source de données sur la table :

CREATE INDEX IX_Cities_CityName
ON Application.Cities (CityName);

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

Quel que soit le moteur de base de données avec lequel vous travaillez réellement, il est toujours préférable de concevoir et d'utiliser des requêtes sargables dans la mesure du possible pour éviter les problèmes de performances. Les requêtes cruciales doivent avoir des index couvrants pour fournir les meilleures performances. Je vous encourage à étudier davantage la sargabilité et les indices de couverture pour vous aider à éviter de concevoir des requêtes qui sont en fait non-sargables.

Conclusion

Nous avons examiné comment Access gère l'application de filtres d'Access SQL dans les requêtes ODBC. Nous avons également exploré différents cas où Access convertira différents types de références en un paramètre, permettant à Access d'effectuer l'évaluation en dehors de la couche ODBC et de les transmettre en tant qu'entrées dans l'instruction ODBC préparée. Nous avons également examiné ce qui se passe lorsqu'il ne peut pas être paramétré, généralement en raison du fait qu'il contient des références de colonne en tant qu'entrées. Cela peut avoir des conséquences sur les performances lors d'une migration vers SQL Server.

Pour certaines fonctions, Access peut être en mesure de convertir l'expression pour utiliser les fonctions scalaires ODBC à la place, ce qui permet à Access d'éloigner l'expression de la source de données ODBC. Une ramification de ceci est que si l'implémentation de la fonction scalaire est différente, cela peut entraîner un comportement différent de la requête ou une exécution plus rapide/lente. Nous avons vu comment une fonction VBA, même une simple qui encapsule une fonction scalaire autrement accessible à distance, peut vaincre les efforts visant à éloigner l'expression. Nous apprenons également que si nous avons une situation où nous ne pouvons pas refactoriser une fonction VBA complexe à partir d'une requête Access/recordsource/rowsource, nous pouvons au moins atténuer le téléchargement coûteux en ajoutant des filtres supplémentaires sur la requête qui peuvent être distants pour réduire le montant de données renvoyées.

Dans le prochain article, nous verrons comment les jointures sont gérées par Access.

Vous cherchez de l'aide avec Microsoft Access ? Appelez nos experts dès aujourd'hui au 773-809-5456 ou envoyez-nous un e-mail à [email protected].