View a markdown version of this page

Différences entre les versions 2.x et 1.x du pilote ODBC - Amazon Redshift
Principales différences à résoudreChaîne de connexion et options DSNChangements de type de donnéesPost-migration dépannageMise à niveau depuis une ancienne version ODBC 2.xEn savoir plus

Amazon Redshift ne prendra plus en charge l'utilisation des UDF Python après le 30 juin 2026. Nous allons commencer à l'appliquer par étapes. Pour plus d'informations sur les détails de la fin de vie de Python et des options de migration, consultez le billet de blog publié le 30 juin 2025.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Différences entre les versions 2.x et 1.x du pilote ODBC

Cette section décrit les différences entre le pilote ODBC 1.x et le pilote ODBC 2.x et fournit des conseils sur la manière de migrer vers le pilote 2.x. Il décrit les modifications susceptibles d'affecter votre candidature et la manière d'y remédier.

Principales différences à résoudre

Les actions suivantes permettent de résoudre les problèmes de migration les plus courants. La plupart des applications n'ont besoin que d'un sous-ensemble de celles-ci.

DSN et chaîne de connexion

  • Vérifiez votre DSN pour les options de pilote susceptibles d'avoir été supprimées ou renommées. Certaines options du pilote ODBC 1.x ne sont pas prises en charge dans le pilote ODBC 2.x. D'autres ont été renommés. Consultez Chaîne de connexion et options DSN pour plus de détails.

  • Définissez UseUnicode=true si votre application dépend de codes de type à caractères larges (SQL_WVARCHAR,SQL_WCHAR). Dans le pilote ODBC 2.x, la UseUnicode valeur par défaut estfalse, ce qui indique les types de caractères restreints.

  • Déplacez les paramètres de journalisation vers la [ODBC] section. Sur Linux et macOS, LogLevel et LogPath doit être défini dans la [ODBC] section globale deodbc.ini, et non dans une section DSN individuelle.

Requête et schéma

  • Inclure EXTERNAL TABLE dans les filtres SQLTables de type. Dans ODBC 2.x, les tables Amazon Redshift Spectrum et les tables de partage de données sont signalées comme. EXTERNAL TABLE Si vous filtrez SQLTables par type, EXTERNAL TABLE ajoutez-en pour continuer à voir ces objets. Vous pouvez également définir l'EnableTableTypesoption sur 0 pour normaliser les informations détaillées sur les types de table dans les types de table génériques TABLE et VIEW, comme décrit dans l'élément suivant.

  • Les types de tableaux détaillés sont activés par défaut. ODBC 2.x active EnableTableTypes cette option par défaut. Le pilote 1.x a désactivé cette option par défaut. Avec la version 2.x par défaut, SQLTables les types de rapports détaillés tels que SYSTEM TABLE, SYSTEM VIEW, EXTERNAL TABLE et LOCAL TEMPORARY sont signalés. Pour signaler chaque table en tant que type générique TABLE et chaque vue en tant que VIEW, définissez EnableTableTypes sur 0.

  • Diffuser INTERVAL vers VARCHAR pour les applications qui ne prennent pas en charge le type de données d'intervalle. Certains clients ne prennent pas en charge les types d'intervalles ODBC. Pour ces clients, créez la colonne de votre requête : SELECT col::VARCHAR FROM ...

Code de demande

  • Vérifiez les paramètres de délai d'expiration des requêtes. ODBC 2.x s'applique correctement SQL_ATTR_QUERY_TIMEOUT conformément à la spécification ODBC. ODBC 1.x a ignoré ce paramètre en silence. Long-running les requêtes qui réussissaient auparavant peuvent désormais échouer avec une erreur de temporisation. Vérifiez et ajustez vos valeurs de délai d'attente si nécessaire.

  • Indiquez la longueur des données pour les paramètres de données lors de l'exécution. 2.x rapporte SQL_NEED_LONG_DATA_LEN comme Y (1.x déclaréN). Les applications qui lient SQL_DATA_AT_EXEC des paramètres doivent désormais fournir la longueur totale des données dès le départStrLen_or_IndPtr.

Chaîne de connexion et options DSN

Le tableau suivant présente les options du pilote ODBC 1.x qui ont été renommées ou ont des équivalents directs dans le pilote ODBC 2.x.

Option 1.x Équivalent à la version 2.x Remarques
MaxLongVarChar MaxLongVarcharSize La valeur par défaut est passée de 8190 à 65535.
ConnectionTimeout LoginTimeout Même délai de connexion, renommé. La valeur par défaut est 0 (aucun délai d'attente).
VpcEndpointUrl vpc_endpoint_url
SSLCertPath TrustStore ou CaFile Chemin d'accès à un certificat CA utilisé pour vérifier le serveur. Sous Windows, définissez cette option dans le champ Trust Store de la boîte de dialogue de configuration DSN ; la boîte de dialogue ne comporte aucun CaFile champ. Si les deux sont paramétrés, TrustStore c'est prioritaire.

Les options 1.x suivantes ne sont pas prises en charge dans le pilote 2.x actuel. Le pilote 2.x les ignore, de sorte qu'ils n'affectent pas votre connexion. Les supprimer de votre DSN est facultatif mais recommandé pour éviter toute confusion.

  • SingleRowMode— pour limiter la mémoire du client, utilisez StreamingCursorRows plutôt.

  • UseSystemTrustStore— non pris en charge. Sous Windows, le pilote 1.x pouvait valider le certificat du serveur par rapport au magasin de certificats système Windows. Le pilote 2.x valide par rapport à un fichier de certificat CA : il utilise le certificat racine Amazon Redshift fourni par défaut, ou le fichier que vous spécifiez dans ou. TrustStore CaFile

  • TextAsLongVarchar,CheckCertRevocation,EnableAwsSdkLogs,UseLogPrefix,Locale,UseDeclareFetch,UseMultipleStatements, EnforceSingleStatement — aucun équivalent dans la version actuelle. L'équipe Amazon Redshift évalue des équivalents ou des alternatives pour ces options dans les prochaines versions.

Pour obtenir la liste complète des options 2.x prises en charge, consultezOptions du pilote ODBC.

Changements de type de données

Le tableau suivant présente les mappages de types de données Amazon Redshift qui ont été modifiés dans ODBC 2.x pour se conformer à la spécification ODBC. La plupart des applications ne sont pas affectées car elles lient les colonnes par index ou par nom plutôt que par code de type.

Type de données Amazon Redshift ODBC 1.x ODBC 2.x
DOUBLE PRECISION SQL_FLOAT(6) SQL_DOUBLE (8)
INTERVAL YEAR TO MONTH SQL_VARCHAR(12), texte SQL_INTERVAL_YEAR_TO_MONTH(107), structure d'intervalles
INTERVAL DAY TO SECOND SQL_VARCHAR(12), texte SQL_INTERVAL_DAY_TO_SECOND(110), structure d'intervalles
VARCHAR / CHAR / TEXT Types étendus (SQL_WVARCHAR,SQL_WCHAR,SQL_WLONGVARCHAR) ; par défaut UseUnicode=true Types étroits (SQL_VARCHAR,SQL_CHAR,SQL_LONGVARCHAR). Réglez UseUnicode=true pour restaurer des types étendus.
GEOMETRY/GEOGRAPHY(commeSQL_C_BINARY) Hex-encoded chaîne ASCII octets binaires bruts

Les COLUMN_SIZE valeurs renvoyées par ont SQLColumns également changé pour GEOMETRYGEOGRAPHY, et les types de SUPER données, qui renvoient désormais NULL pour indiquer les colonnes non dimensionnées conformément à la spécification ODBC. Les applications qui allouent des buffers en fonction de COLUMN_SIZE doivent gérer NULL en utilisant une taille de tampon par défaut.

Post-migration dépannage

Le tableau suivant décrit les problèmes courants que vous pouvez rencontrer après la migration et explique comment les résoudre.

Symptôme Cause Que faire
Les tables externes ne sont pas visibles dans le navigateur de schémas Les tableaux de spectre et de partage de données sont présentés comme EXTERNAL TABLE EXTERNAL TABLEÀ inclure dans votre filtre de SQLTables type ou EnableTableTypes à définir sur 0 pour normaliser les types de tableaux détaillés dans les types génériques TABLE et VIEW.
erreurs pyodbc sur les colonnes d'intervalle pyodbc ne prend pas en charge les types d'intervalles ODBC Convertissez les intervalles VARCHAR en requêtes.
Les données des caractères s'affichent sous forme de caractères inattendus (mojibake) UseUnicodela valeur par défaut a été modifiée enfalse. Les applications qui attendent des données à caractères larges (UTF-16) peuvent mal interpréter les octets à caractères étroits comme des paires larges, ce qui entraîne une sortie confuse. Les données elles-mêmes restent inchangées. Définissez UseUnicode=true dans votre DSN ou mettez à jour votre application pour lier les colonnes au SQL_C_CHAR lieu deSQL_C_WCHAR.
Long-running les requêtes renvoient des erreurs de délai d'expiration SQL_ATTR_QUERY_TIMEOUTest désormais en vigueur. ODBC 1.x a ignoré ce paramètre en silence. Augmentez ou supprimez QueryTimeout de votre DSN, ou réglez-le SQL_ATTR_QUERY_TIMEOUT sur 0 dans votre application.
Paramétrer les SQL_ATTR_CURRENT_CATALOG retours HY011 L'attribut ne peut pas être défini sur une connexion ouverte. Le changement de base de données sur une connexion ouverte n'est pas pris en charge. Définissez l'attribut avant de vous connecter, ou fermez et rouvrez la connexion sur la base de données cible.
La connexion se bloque dans les environnements à double pile Limitation dans les versions <= 2.1.16 Passez à la version 2.1.17 ou ultérieure.
L'analyse des messages d'erreur renvoie des résultats inattendus Format du message modifié ; codes SQLSTATE inchangés Analysez les codes SQLSTATE au lieu du texte du message.
Data-at-execution la liaison de paramètres se comporte différemment SQL_NEED_LONG_DATA_LENest passé de FALSE à TRUE ; les applications utilisant SQL_DATA_AT_EXEC doivent désormais fournir la longueur totale des données à l'avance Définissez la valeur de longueur StrLen_or_IndPtr lors de la liaison SQL_DATA_AT_EXEC des paramètres.
Les journaux des pilotes ne sont pas générés LogLevelet LogPath doit figurer dans la section [ODBC] globale deodbc.ini, et non dans les sections DSN individuelles Déplacez les paramètres de journalisation de votre DSN vers la [ODBC] section.

Mise à niveau depuis une ancienne version ODBC 2.x

Si vous utilisez déjà une ancienne version d'ODBC 2.x, passez à la dernière version. Pour obtenir la liste complète des améliorations et des corrections de bogues apportées à toutes les versions, consultez la page consacrée aux modifications du pilote ODBC Amazon Redshift. GitHub

En savoir plus