Considérations sur les fonctionnalités de base de données à utiliser

Une fois que le niveau de base de l’interopérabilité est connu, les fonctionnalités de base de données utilisées par l’application doivent être prises en compte. Par exemple, quelles instructions SQL l’application s’exécute-t-elle ? L’application utilisera-t-elle des curseurs défilants ? Transactions ? Procédures? Données longues ? Pour obtenir des idées sur les fonctionnalités qui peuvent ne pas être prises en charge par tous les SGBD, consultez les descriptions des fonctions SQLGetInfo, SQLSet Connecter Attr et SQLSetStmtAttr, ainsi que l’annexe C : grammaire SQL. Les fonctionnalités requises par une application peuvent éliminer certains SGBD de la liste des SGBD cibles. Ils peuvent également montrer que l’application peut facilement cibler de nombreux SGBD.

Par exemple, si les fonctionnalités requises sont simples, elles peuvent généralement être implémentées avec un degré élevé d’interopérabilité. Une application qui exécute une instruction SELECT simple et récupère les résultats avec un curseur en avant uniquement est susceptible d’être hautement interopérable en raison de sa simplicité : presque tous les pilotes et SGBD prennent en charge les fonctionnalités dont il a besoin.

Toutefois, si les fonctionnalités requises sont plus complexes, telles que les curseurs à défilement, les instructions de mise à jour et de suppression positionnées et les procédures, les compromis doivent souvent être effectués. Il existe plusieurs possibilités :

• Interopérabilité plus faible, plus de fonctionnalités. L’application inclut les fonctionnalités, mais fonctionne uniquement avec les SGBD qui les prennent en charge.

• Interopérabilité plus élevée, moins de fonctionnalités. L’application supprime les fonctionnalités, mais fonctionne avec plus de SGBD.

• Interopérabilité plus élevée, fonctionnalités facultatives. L’application inclut les fonctionnalités, mais les rend disponibles uniquement avec les SGBD qui les prennent en charge.

• Plus d’interopérabilité, plus de fonctionnalités. L’application utilise les fonctionnalités avec des SGBD qui les prennent en charge et les émule pour les SGBD qui ne le font pas.

Les deux premiers cas sont relativement simples à implémenter, car les fonctionnalités sont utilisées avec tous les SGBD pris en charge ou sans aucun. Les deux derniers cas, d’autre part, sont plus complexes. Dans les deux cas, il est nécessaire de case activée si le SGBD prend en charge les fonctionnalités et, dans le dernier cas, pour écrire une grande quantité de code pour émuler ces fonctionnalités. Par conséquent, ces schémas sont susceptibles de nécessiter davantage de temps de développement et peuvent être plus lents au moment de l’exécution.

Considérez une application de requête générique qui peut se connecter à une seule source de données. L’application accepte une requête de l’utilisateur et affiche les résultats dans une fenêtre. Supposons maintenant que cette application dispose d’une fonctionnalité qui permet aux utilisateurs d’afficher simultanément les résultats de plusieurs requêtes. Autrement dit, ils peuvent exécuter une requête et examiner certains des résultats, exécuter une autre requête et examiner certains de ses résultats, puis revenir à la première requête. Cela présente un problème d’interopérabilité, car certains pilotes ne prennent en charge qu’une seule instruction active.

L’application a un certain nombre de choix, en fonction de ce que le pilote retourne pour l’option SQL_MAX_CONCURRENT_ACTIVITIES dans SQLGetInfo :

• Prenez toujours en charge plusieurs requêtes. Après la connexion à un pilote, l’application case activée le nombre d’instructions actives. Si le pilote ne prend en charge qu’une seule instruction active, l’application ferme la connexion et informe l’utilisateur que le pilote ne prend pas en charge les fonctionnalités requises. L’application est facile à implémenter et dispose de fonctionnalités complètes, mais a une interopérabilité inférieure.

• Ne prend jamais en charge plusieurs requêtes. L’application supprime complètement la fonctionnalité. Il est facile d’implémenter et d’avoir une interopérabilité élevée, mais a moins de fonctionnalités.

• Prise en charge de plusieurs requêtes uniquement si le pilote le fait. Après la connexion à un pilote, l’application case activée le nombre d’instructions actives. L’application permet à l’utilisateur de démarrer une nouvelle instruction lorsqu’une instruction est déjà active uniquement si le pilote prend en charge plusieurs instructions actives. L’application dispose d’une fonctionnalité et d’une interopérabilité plus élevées, mais elle est plus difficile à implémenter.

• Prenez toujours en charge plusieurs requêtes et émulez-les si nécessaire. Après la connexion à un pilote, l’application case activée le nombre d’instructions actives. L’application permet toujours à l’utilisateur de démarrer une nouvelle instruction lorsqu’elle est déjà active. Si le pilote ne prend en charge qu’une seule instruction active, l’application ouvre une connexion supplémentaire à ce pilote et exécute la nouvelle instruction sur cette connexion. L’application dispose de fonctionnalités complètes et d’une interopérabilité élevée, mais elle est plus difficile à implémenter.