View a markdown version of this page

Diferencias entre las versiones 2.x y 1.x del controlador ODBC - Amazon Redshift
Diferencias clave que abordarOpciones de cadena de conexión y DSNCambios del tipo de datosSolución de problemas posteriores a la migraciónActualización desde una versión anterior de ODBC 2.xMás información

Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la publicación del blog.

Diferencias entre las versiones 2.x y 1.x del controlador ODBC

En esta sección se describen las diferencias entre el controlador ODBC 1.x y el controlador ODBC 2.x, y se proporciona orientación sobre cómo migrar al controlador 2.x. En ella se describen los cambios que pueden afectar a la aplicación y cómo abordarlos.

Diferencias clave que abordar

Las siguientes acciones resuelven los problemas de migración más comunes. La mayoría de las aplicaciones solo necesitan un subconjunto de estas.

DSN y cadena de conexión

  • Revise el DSN para ver las opciones de controlador que podrían haberse eliminado o cambiado de nombre. Algunas opciones del controlador ODBC 1.x no son compatibles con el controlador ODBC 2.x. Se ha cambiado el nombre de otras. Para obtener más información, consulte Opciones de cadena de conexión y DSN.

  • Configure UseUnicode=true si la aplicación depende de códigos de tipos de caracteres anchos (SQL_WVARCHAR, SQL_WCHAR). En el controlador ODBC 2.x, el valor UseUnicode predeterminado es false, que indica tipos de caracteres restringidos.

  • Mueva la configuración de registro a la sección [ODBC]. En Linux y macOS, LogLevel y LogPath se deben configurar en la sección [ODBC] global de odbc.ini, no en una sección individual de DSN.

Consulta y esquema

  • Incluya EXTERNAL TABLE en los filtros de tipo SQLTables. En ODBC 2.x, tanto las tablas de Amazon Redshift Spectrum como las tablas de recurso compartido de datos se presentan como EXTERNAL TABLE. Si filtra SQLTables por tipo, agregue EXTERNAL TABLE para seguir viendo estos objetos.

  • Convierta INTERVAL en VARCHAR para aplicaciones que no admiten el tipo de datos de intervalo. Algunos clientes no admiten los tipos de intervalos ODBC. Para esos clientes, convierta la columna en la consulta: SELECT col::VARCHAR FROM ...

Código de la aplicación

  • Verifique la configuración del tiempo de espera de la consulta. ODBC 2.x aplica correctamente SQL_ATTR_QUERY_TIMEOUT según la especificación de ODBC. ODBC 1.x ignoró silenciosamente esta configuración. Las consultas de larga duración que antes se realizaban correctamente ahora pueden producir un error y provocar un error de tiempo de espera. Revise y ajuste los valores de tiempo de espera según sea necesario.

  • Proporcione la longitud de los datos para los parámetros de los datos en el momento de la ejecución. 2.x informa de SQL_NEED_LONG_DATA_LEN como Y (1.x ha informado de N). Las aplicaciones que enlazan parámetros SQL_DATA_AT_EXEC ahora deben proporcionar la longitud total de los datos por adelantado en StrLen_or_IndPtr.

Opciones de cadena de conexión y DSN

La siguiente tabla muestra las opciones del controlador ODBC 1.x a las que se ha cambiado el nombre o que tienen equivalentes directos en el controlador ODBC 2.x.

Opción 1.x Equivalente en 2.x Notas
MaxLongVarChar MaxLongVarcharSize Se ha cambiado de forma predeterminada de 8190 a 65535.
ConnectionTimeout LoginTimeout El mismo tiempo de espera de conexión, pero se ha cambiado el nombre. El valor predeterminado es 0 (sin tiempo de espera).
VpcEndpointUrl vpc_endpoint_url
SSLCertPath TrustStore o CaFile Ruta a un certificado CA utilizado para verificar el servidor. En Windows, establezca esto en el campo Almacén de confianza del cuadro de diálogo de configuración de DSN; el cuadro de diálogo no tiene ningún campo CaFile. Si ambos están configurados, TrustStore tiene prioridad.

El controlador 2.x actual no admite las siguientes opciones de 1.x. El controlador 2.x las ignora, por lo que no afectan a la conexión. Eliminarlos del DSN es opcional, pero se recomienda eliminarlos para evitar confusiones.

  • SingleRowMode: para limitar la memoria del cliente, utilice StreamingCursorRows en su lugar.

  • UseSystemTrustStore: no compatible. En Windows, el controlador 1.x podía validar el certificado del servidor con el almacén de certificados del sistema de Windows. El controlador 2.x se valida con un archivo de certificado CA: utiliza el certificado raíz de Amazon Redshift agrupado de forma predeterminada o el archivo que especifique en TrustStore o CaFile.

  • BoolsAsChar: si la aplicación se basaba en que las columnas BOOLEANAS se devolvían como cadenas "0" y "1" (SQL_VARCHAR), convierta la columna en VARCHAR en la consulta, por ejemplo SELECT col::VARCHAR FROM ....

  • TextAsLongVarchar, CheckCertRevocation, EnableAwsSdkLogs, UseLogPrefix, Locale, UseDeclareFetch, UseMultipleStatements, EnforceSingleStatement, EnableTableTypes: no hay equivalente en la versión actual. El equipo de Amazon Redshift está evaluando equivalentes o alternativas para estas opciones en futuras versiones.

Para obtener una lista completa de opciones de 2.x admitidas, consulte Opciones del controlador ODBC.

Cambios del tipo de datos

La siguiente tabla muestra las asignaciones de tipos de datos de Amazon Redshift que se modificaron en ODBC 2.x para cumplir con la especificación de ODBC. La mayoría de las aplicaciones no se ven afectadas porque enlazan las columnas por índice o nombre en lugar de por código de tipo.

Tipos de datos de Amazon Redshift ODBC 1.x ODBC 2.x
DOUBLE PRECISION SQL_FLOAT (6) SQL_DOUBLE (8)
INTERVAL YEAR TO MONTH SQL_VARCHAR (12), texto SQL_INTERVAL_YEAR_TO_MONTH (107), estructura de intervalos
INTERVAL DAY TO SECOND SQL_VARCHAR (12), texto SQL_INTERVAL_DAY_TO_SECOND (110), estructura de intervalos
VARCHAR / CHAR / TEXT Tipos anchos (SQL_WVARCHAR, SQL_WCHAR, SQL_WLONGVARCHAR); de forma predeterminada UseUnicode=true Tipos estrechos (SQL_VARCHAR, SQL_CHAR, SQL_LONGVARCHAR). Se configura UseUnicode=true para restaurar tipos anchos.
GEOMETRY / GEOGRAPHY (como SQL_C_BINARY) Cadena ASCII codificada en hexadecimal Bytes binarios sin procesar

Los valores COLUMN_SIZE devueltos por SQLColumns también cambiaron para los tipos de datos GEOMETRY, GEOGRAPHY y SUPER, que ahora devuelven NULL para indicar columnas sin tamaño según la especificación de ODBC. Las aplicaciones que asignan búferes en función de COLUMN_SIZE deben gestionar NULL con un tamaño de búfer predeterminado.

Solución de problemas posteriores a la migración

En la siguiente tabla se describen los problemas comunes que puede encontrar después de la migración y cómo resolverlos.

Síntoma Causa Solución
Las tablas externas no están visibles en el navegador de esquemas Las tablas de Spectrum y recurso compartido de datos se presentan como EXTERNAL TABLE Incluya EXTERNAL TABLE en el tipo de filtro SQLTables.
Errores de pyodbc en las columnas de intervalos pyodbc no admite los tipos de intervalos ODBC Convierta intervalos en VARCHAR en consultas.
Los datos de los caracteres se muestran como caracteres inesperados (mojibake) UseUnicode predeterminado cambiado a false. Las aplicaciones que esperan datos de caracteres anchos (UTF-16) pueden malinterpretar los bytes de caracteres estrechos como pares anchos y producir resultados confusos. Los datos en sí no han cambiado. Configure UseUnicode=true en el DSN o actualice la aplicación para que enlace columnas como SQL_C_CHAR en lugar de SQL_C_WCHAR.
Las consultas de larga duración devuelven errores de tiempo de espera SQL_ATTR_QUERY_TIMEOUT ahora se aplica. ODBC 1.x ignoró silenciosamente esta configuración. Aumente o elimine QueryTimeout del DSN, o establezca SQL_ATTR_QUERY_TIMEOUT en 0 en la aplicación.
La configuración de SQL_ATTR_CURRENT_CATALOG devuelve HY011 El atributo no se puede establecer en una conexión abierta. No se admite el cambio de bases de datos en una conexión abierta. Establezca el atributo antes de conectarse o cierre y vuelva a abrir la conexión en la base de datos de destino.
La conexión se bloquea en entornos de doble pila Limitación en las versiones <=2.1.16 Actualice a 2.1.17 o versiones posteriores.
El análisis de los mensajes de error arroja resultados inesperados El formato del mensaje ha cambiado; los códigos SQLSTATE no han cambiado Analice los códigos SQLSTATE en lugar del texto del mensaje.
El enlace de parámetros de datos en el momento de la ejecución se comporta de forma diferente SQL_NEED_LONG_DATA_LEN cambió de FALSE a TRUE; las aplicaciones que utilizan ahora SQL_DATA_AT_EXEC deben proporcionar la longitud total de los datos por adelantado Establezca el valor de longitud en StrLen_or_IndPtr al vincular los parámetros SQL_DATA_AT_EXEC.
No se han generado los registros de los controladores LogLevel y LogPath deben estar en la sección global de [ODBC] de odbc.ini, no en las secciones de DSN individuales Mueva la configuración de registro del DSN a la sección de [ODBC].

Actualización desde una versión anterior de ODBC 2.x

Si ya utiliza una versión anterior de ODBC 2.x, actualice a la versión más reciente. Para obtener una lista completa de mejoras y correcciones de errores en todas las versiones, consulte el registro de cambios del controlador ODBC de Amazon Redshift en GitHub.

Más información