Mise à niveau d’un pilote 3.5 vers un pilote 3.8
Cette rubrique fournit des instructions et des considérations relatives à la mise à niveau d’un pilote ODBC 3.5 vers un pilote ODBC 3.8.
Numéros de versions
Les instructions suivantes concernent les numéros de version :
Un pilote doit prendre en charge SQL_OV_ODBC3_80 pour SQL_ATTR_ODBC_VERSION, en retournant SQL_ERROR pour les valeurs autres que SQL_OV_ODBC2, SQL_OV_ODBC3 et SQL_OV_ODBC3_80. Les futures versions du Gestionnaire de pilotes supposent qu’un pilote prend en charge un niveau de conformité ODBC si le pilote retourne SQL_SUCCESS à partir de la fonction SQLSetEnvAttr.
Un pilote version 3.8 doit retourner 03.80 à partir de SQLGetInfo quand SQL_DRIVER_ODBC_VER est passé à InfoType. Toutefois, les gestionnaires de pilotes plus anciens, inclus dans les versions antérieures de Microsoft Windows, traitent le pilote comme un pilote 3.5 et émettent un avertissement.
Dans Windows 7, la version du Gestionnaire de pilotes est 03.80. Dans Windows 8, la version du Gestionnaire de pilotes est 03.81 via le SQL_DM_VER SQLGetInfo (paramètre InfoType ). SQL_ODBC_VER signale la version 03.80 dans Windows 7 et Windows 8.
Types de données C spécifiques au pilote
Un pilote peut avoir des types de données C personnalisés lorsqu’il fonctionne avec une application ODBC version 3.8. (Pour plus d’informations, consultez Types de données C dans ODBC.) Toutefois, il n’est pas nécessaire qu’un pilote 3.8 implémente tous les types C spécifiques au pilote. Mais le pilote doit toujours effectuer la vérification de la plage des types C ; Le Gestionnaire de pilotes ne le fera pas pour les pilotes 3.8. Pour faciliter le développement de pilotes, la valeur du pilote spécifique, le type de données C peut être défini au format suivant :
SQL_DRIVER_C_TYPE_BASE+0, SQL_DRIVER_C_TYPE_BASE+1
Types de données spécifiques au pilote, types de descripteur, types d’informations, types de diagnostic et attributs
Lors du développement d’un nouveau pilote, vous devez utiliser la plage spécifique au pilote pour les types de données, les types de descripteur, les types d’informations, les types de diagnostic et les attributs. Les plages spécifiques au pilote et leurs valeurs de type de base sont présentées dans les types de données spécifiques au pilote, les types de descripteur, les types d’informations, les types d’informations, les types de diagnostic et les attributs.
Regroupement de connexions
Pour une meilleure gestion du regroupement de connexions, ODBC 3.8 introduit l’attribut de connexion SQL_ATTR_RESET_CONNECTION dans SQLSetConnectAttr. SQL_RESET_CONNECTION_YES est la seule valeur valide pour cet attribut. SQL_ATTR_RESET_CONNECTION sera définie juste avant que le Gestionnaire de pilotes place une connexion dans le pool de connexions, ce qui permet au pilote de réinitialiser les autres attributs de connexion à leurs valeurs par défaut.
Pour éviter toute communication inutile avec le serveur, un pilote peut différer la réinitialisation de l’attribut de connexion jusqu’à la communication suivante avec le serveur distant, une fois la connexion réutilisée à partir du pool.
Notez que SQL_ATTR_RESET_CONNECTION est utilisé uniquement dans la communication entre le Gestionnaire de pilotes et un pilote. Une application ne peut pas définir cet attribut directement. Tous les pilotes de la version 3.8 doivent implémenter cet attribut de connexion.
Paramètres de sortie diffusés en continu
ODBC version 3.8 introduit des paramètres de sortie diffusés en continu, un moyen plus évolutif de récupérer les paramètres de sortie. (Pour plus d’informations, consultez Récupération des paramètres de sortie à l’aide de SQLGetData.) Pour prendre en charge cette fonctionnalité, un pilote doit définir SQL_GD_OUTPUT_PARAMS dans la valeur de retour lorsque SQL_GETDATA_EXTENSIONS est infoType dans un appel SQLGetInfo. La prise en charge d’un type SQL avec des paramètres de sortie en flux doit être implémentée dans le pilote. Le Gestionnaire de pilotes ne génère pas d’erreur pour un type SQL non valide. Les types SQL qui prennent en charge les paramètres de sortie diffusés en continu sont définis dans le pilote.
Un pilote doit retourner SQL_ERROR si l’application a utilisé SQLGetData pour récupérer un paramètre qui n’est pas le même que le paramètre retourné par SQLParamData.
Exécution asynchrone pour les opérations de connexion (méthode d’interrogation)
Un pilote peut activer la prise en charge asynchrone de différentes opérations de connexion.
À compter de Windows 7, ODBC prend en charge la méthode d’interrogation (pour plus d’informations, consultez Exécution asynchrone (méthode d’interrogation). Il n’est pas nécessaire qu’un pilote ODBC version 3.8 implémente des opérations asynchrones sur les handles de connexion. Même si un pilote n’implémente pas d’opérations asynchrones sur les handles de connexion, le pilote doit toujours implémenter le SQL_ASYNC_DBC_FUNCTIONS InfoType et retourner SQL_ASYNC_DBC_NOT_CAPABLE.
Lorsque des opérations de connexion asynchrones sont activées, l’heure d’exécution d’une opération de connexion est la durée totale de tous les appels répétés. Si le dernier appel répété se produit après que le temps total a dépassé la valeur définie par l’attribut de connexion SQL_ATTR_CONNECTION_TIMEOUT et que l’opération n’a pas terminé, le pilote retourne SQL_ERROR et enregistre un enregistrement de diagnostic avec SQLState HYT01 et le message « Délai d’expiration de la connexion a expiré ». Il n’y a pas de délai d’expiration si l’opération s’est terminée.
SQLCancelHandle, fonction
ODBC 3.8 prend en charge la fonction SQLCancelHandle, qui est utilisée pour annuler les opérations de connexion et d’instruction. Un pilote qui prend en charge SQLCancelHandle doit exporter la fonction. Un pilote ne doit annuler aucune fonction de connexion synchrone ou asynchrone en cours si l’application appelle SQLCancel ou SQLCancelHandle sur un handle d’instruction. De même, un pilote ne doit pas annuler une fonction d’instruction synchrone ou asynchrone en cours si une application appelle SQLCancelHandle sur le handle de connexion. En outre, un pilote ne doit pas annuler l’opération de navigation (SQLBrowseConnect retourne SQL_NEED_DATA) si l’application appelle SQLCancelHandle sur le handle de connexion. Dans ces cas, un pilote doit retourner HY010, « erreur de séquence de fonction ».
Il n’est pas nécessaire de prendre en charge les opérations de connexion SQLCancelHandle et asynchrones en même temps. Un pilote peut prendre en charge les opérations de connexion asynchrones, mais pas SQLCancelHandle, ou inversement.
Connexions suspendues
Le Gestionnaire de pilotes ODBC 3.8 peut mettre une connexion en état suspendu. Une application appelle SQLDisconnect pour libérer des ressources associées à la connexion. Dans ce cas, un pilote doit essayer de libérer autant de ressources que possible sans vérifier l’état de la connexion. Pour plus d’informations sur l’état suspendu, consultez la fonction SQLEndTran.
Regroupement de connexions prenant en charge les pilotes
ODBC dans Windows 8 permet aux pilotes de personnaliser le comportement du pool de connexions. Pour plus d’informations, consultez Regroupement de connexions prenant en charge les pilotes.
Exécution asynchrone (méthode de notification)
ODBC 3.8 prend en charge la méthode de notification pour les opérations asynchrones, disponible à partir de Windows 8. Pour plus d’informations, consultez Exécution asynchrone (méthode de notification).
Voir aussi
Développement d’un pilote ODBC
Pilotes ODBC fournis par Microsoft
Nouveautés d’ODBC 3.8