Comment optimiser Microsoft Access lors de l’utilisation de sources de données ODBC

Avancé : nécessite des compétences d’experts en codage, en interopérabilité et en multi-utilisateur.

Cet article sʼapplique uniquement à une base de données Microsoft Access (.mdb ou .accdb).

Résumé

Cet article décrit plusieurs conseils pour améliorer les performances lorsque vous accédez aux données à partir d’une source de données ODBC.

Informations supplémentaires

Utilisez les conseils suivants pour améliorer les performances avec les sources de données ODBC :

• Limitez la quantité de données que vous demandez au serveur. Ne demandez pas plus de données que nécessaire. Utilisez des requêtes pour sélectionner uniquement les champs et les lignes dont vous avez besoin.

• Utilisez uniquement les fonctionnalités dont vous avez besoin. Les instantanés sont moins puissants que les feuilles dynamiques et ne peuvent pas être mis à jour. Toutefois, les instantanés peuvent être plus rapides, en particulier pour les jeux d’enregistrements de petite taille sans champs Mémo ou Objet OLE.

• Créez des tables liées (attachées) pour accéder aux données du serveur. Évitez l’accès « direct » au serveur (autrement dit, n’ouvrez pas de bases de données distantes et n’exécutez pas de requêtes sur celles-ci). Au lieu de cela, créez des tables jointes ou créez des requêtes directes.

• Concevez des zones de liste et des zones de liste déroulante à bon escient. Dans un formulaire, chaque zone de liste, zone de liste modifiable, sous-formulaire et contrôle qui contient un total nécessite une requête distincte. Par rapport aux données locales, les performances peuvent être suffisantes. Toutefois, pour les données distantes, de longs délais peuvent se produire lorsque vous ouvrez un formulaire, car chaque requête doit être envoyée au serveur et une réponse doit être retournée avant que le formulaire puisse être ouvert.

• Évitez les grandes zones de liste déroulante. L’inclusion d’une zone de liste modifiable avec des centaines, voire des milliers, de choix basés sur une table locale peut générer un temps de réponse acceptable, en particulier si vous définissez un index approprié sur la table locale. Toutefois, sur une table distante, une telle zone de liste déroulante génère des performances lentes, car elle draine les ressources du serveur et du réseau à mesure qu’elle extrait les données pour remplir la liste. Il est préférable de limiter le nombre de lignes renvoyées à la zone de liste déroulante lorsque vous utilisez des données distantes. Vous pouvez également diviser les données en zones de liste modifiable plus petites (en gardant à l’esprit le conseil ci-dessus).

• Utilisez la commande Rechercher uniquement sur des jeux d’enregistrements plus petits. Le moteur de base de données Microsoft Jet optimise la commande Find pour qu’elle fonctionne correctement sur les jeux d’enregistrements locaux de presque toutes les tailles et sur les jeux d’enregistrements distants de taille raisonnable. Toutefois, lorsque vous disposez de jeux d’enregistrements distants volumineux (des milliers d’enregistrements ou plus), vous devez plutôt créer un filtre ou une requête et veiller à utiliser les restrictions que votre serveur peut traiter.

• Assurez-vous que les requêtes sont envoyées au serveur pour traitement. Le facteur le plus important dans les performances des requêtes par rapport aux données distantes est de s’assurer que votre serveur exécute la plus grande partie possible de la requête. Le moteur de base de données Microsoft Jet tente d’envoyer la requête entière à votre serveur, mais évalue localement toutes les clauses et expressions de requête qui ne sont généralement pas prises en charge par les serveurs ou par votre serveur particulier. Les fonctionnalités non prises en charge par les serveurs en général incluent les éléments suivants :

• Opérations qui ne peuvent pas être exprimées dans une seule instruction SQL. Cette situation peut se produire lorsque vous utilisez une requête comme entrée d’une autre requête, ou lorsque la clause FROM de votre requête contient une requête Totals ou une requête DISTINCT. Souvent, vous pouvez réorganiser vos requêtes pour calculer des totaux après toutes les autres opérations.

  • Opérations qui sont des extensions propres au moteur de base de données Microsoft Jet pour SQL, telles que les requêtes d’analyse croisée, les requêtes TOP et les rapports avec plusieurs niveaux de regroupement et de totaux. Notez que des requêtes d’analyse croisée simples peuvent être envoyées aux serveurs.
  • Expressions qui contiennent des opérateurs ou des fonctions spécifiques à Microsoft Access. Les fonctions financières et les agrégats statistiques Microsoft Access n’ont pas d’équivalents serveur.
  • Fonctions Visual Basic pour Application définies par l’utilisateur qui prennent des colonnes distantes en tant qu’arguments. Ces fonctions n’existent pas sur le serveur, mais doivent traiter les données de colonne distante. Toutefois, si une fonction définie par l’utilisateur retourne une valeur unique et ne fait pas référence à une colonne distante, la fonction est évaluée localement et sa valeur est envoyée au serveur pour traitement.
  • Mélange de types de données texte et numérique dans des opérateurs ou des sorties de requête UNION. La plupart des serveurs ne disposent pas de la clémence de type de données de Microsoft Access. Pour cette raison, utilisez des fonctions de conversion explicites le cas échéant.
  • Jointures hétérogènes entre des tables locales et des tables distantes, ou entre des tables distantes dans différentes sources de données ODBC. Les jointures entre de petites tables locales et de grandes tables distantes, où la colonne de jointure est indexée, peuvent entraîner une jointure d’index distante. Dans une jointure d’index distante, une requête pour chaque ligne de la table locale est envoyée au serveur, et seules les lignes de jointure sont retournées.
  • Expressions non distantes, ou expressions qui ne peuvent pas être envoyées à distance, car elles ne peuvent pas être évaluées par votre serveur. Les expressions de sortie non distantes (celles de la clause SELECT) ne forcent pas l’évaluation locale de votre requête, sauf si elles se produisent dans une requête Totals, une requête DISTINCT ou une requête UNION. Les expressions non remoteables dans d’autres clauses (WHERE, ORDER BY, GROUP BY, HAVING, etc.) forcent l’évaluation locale d’au moins une partie de votre requête.

• Les serveurs diffèrent dans certains domaines des fonctionnalités prises en charge. Lorsque vous attachez une table distante, le moteur de base de données Microsoft Jet interroge le pilote ODBC pour connaître ses fonctionnalités. Si les fonctionnalités requises sont prises en charge par le pilote et le serveur, le moteur de base de données Microsoft Jet envoie l’opération au serveur pour traitement. Si ce n’est pas le cas, le moteur de base de données Microsoft Jet effectue l’opération localement. Les différents domaines de prise en charge incluent (sans s’y limiter) les éléments suivants :

  • Jointures externes. Notez que le moteur de base de données Microsoft Jet n’envoie pas plusieurs jointures externes à un serveur, bien que de nombreuses jointures internes puissent accompagner une seule jointure externe.
  • Fonctions numériques, de chaîne et de date/heure, telles que Log(), Mid$(), DatePart(), etc.
  • Fonctions de conversion, telles que CInt(), CStr(), CVDate(), etc.