Descripción de las conversiones de tipos de datos
Para facilitar la conversión de tipos de datos del lenguaje de programación Java a tipos de datos de SQL Server, Microsoft JDBC Driver for SQL Server proporciona las conversiones de tipos de datos que necesita la especificación JDBC. Para mejorar la flexibilidad, todos los tipos son convertibles entre los tipos de datos Object, String y byte[].
Nota
Al usar Always Encrypted, es necesario tener consideraciones especiales respecto a las conversiones de tipos de datos. Para obtener más información, consulte Errores de conversión de tipos de datos no compatibles.
Conversiones del método Getter
Según los tipos de datos de SQL Server, el siguiente gráfico contiene el mapa de conversión del controlador JDBC para los métodos get<Type>() de la clase SQLServerResultSet, así como las conversiones admitidas para los métodos get<Type> de la clase SQLServerCallableStatement.
Los métodos de captador del controlador JDBC admiten tres categorías de conversiones:
Sin pérdidas (x): conversiones para los casos en los que el tipo de captador es igual o menor que el tipo de servidor subyacente. Por ejemplo, al llamar a getBigDecimal en una columna decimal del servidor subyacente, no es necesario realizar ninguna conversión.
Convertido (y): conversiones desde tipos de servidores numéricos a tipos del lenguaje Java en las que la conversión es normal y sigue las reglas de conversión del lenguaje Java. Para estas conversiones, la precisión siempre se trunca, nunca se redondea, y el desbordamiento se trata como un módulo del tipo de destino, que es más pequeño. Por ejemplo, al llamar a getInt en una columna decimal subyacente que contiene "1,9999", por ejemplo, se devolverá "1" o si el valor decimal subyacente es "3000000000", el valor int se desborda a "-1294967296".
Dependiente de datos (z): las conversiones de tipos de caracteres subyacentes a tipos numéricos requieren que los tipos de caracteres contengan valores que se puedan convertir a ese tipo. No se realiza ninguna otra conversión. Si el valor es demasiado grande para el tipo de captador, el valor no es válido. Por ejemplo, si se llama a getInt en una columna varchar(50) que contiene "53", el valor se devuelve como int, pero si el valor subyacente es "xyz" o "3000000000", se produce un error.
Si se llama a getString en un tipo de datos de la columna binary, varbinary, varbinary(max) o image, el valor se devuelve como valor de cadena hexadecimal.
Conversiones del método Updater
Para los datos de tipo Java pasados a los métodos update<Type>() de la clase SQLServerResultSet, se aplican las conversiones siguientes.
Los métodos de actualización del controlador JDBC admiten tres categorías de conversiones:
Sin pérdidas (x): conversiones para los casos en los que el tipo de actualizador es igual o menor que el tipo de servidor subyacente. Por ejemplo, al llamar a updateBigDecimal en una columna decimal del servidor subyacente, no es necesario realizar ninguna conversión.
Convertido (y): conversiones desde tipos de servidores numéricos a tipos del lenguaje Java en las que la conversión es normal y sigue las reglas de conversión del lenguaje Java. Para estas conversiones, la precisión siempre se trunca (nunca se redondea) y el desbordamiento se trata como un módulo del tipo de destino (el más pequeño). Por ejemplo, al llamar a updateDecimal en una columna int subyacente que contiene "1,9999", por ejemplo, se devolverá "1" o si el valor decimal subyacente es "3000000000", el valor int se desborda a "-1294967296".
Dependiente de datos (z): las conversiones de tipos de datos de origen subyacentes a tipos de datos de destino requieren que los valores contenidos se puedan convertir a los tipos de destino. No se realiza ninguna otra conversión. Si el valor es demasiado grande para el tipo de captador, el valor no es válido. Por ejemplo, si se llama a updateString en una columna que contiene "53", la actualización se realiza correctamente, pero si el valor String subyacente es "foo" o "3000000000", se genera un error.
Al llamarse a updateString en un tipo de datos de la columna binary, varbinary, varbinary(max) o image, controla el valor String como valor de cadena hexadecimal.
Cuando el tipo de datos de columna de es XML, el valor de los datos debe ser un tipo XML válido. Cuando se llama a los métodos updateBytes, updateBinaryStream o updateBlob, el valor de los datos debe ser la representación de la cadena hexadecimal de los caracteres XML. Por ejemplo:
<hello>world</hello> = 0x3C68656C6C6F3E776F726C643C2F68656C6C6F3E
Tenga en cuenta que se necesita una marca de orden de bytes (BOM) si los caracteres XML están en codificaciones de caracteres específicos.
Conversiones del método Setter
Para los datos de tipo Java pasados a los métodos set<Type>() de la clase SQLServerPreparedStatement y de la clase SQLServerCallableStatement, se aplican las siguientes conversiones.
El servidor intenta realizar las conversiones y devuelve errores si no lo consigue.
En el caso del tipo de datos String, si el valor supera la longitud deVARCHAR, se asigna a LONGVARCHAR. Del mismo modo, NVARCHAR se asigna a LONGNVARCHAR si el valor supera la longitud admitida de NVARCHAR. Lo mismo sucede para byte[]. Los valores mayores que VARBINARY pasan a ser LONGVARBINARY.
Los métodos de establecimiento del controlador JDBC admiten dos categorías de conversiones:
Sin pérdidas (x): conversiones para los casos numéricos en los que el tipo de establecedor es igual o menor que el tipo de servidor subyacente. Por ejemplo, al llamar a setBigDecimal en una columna decimal del servidor subyacente, no es necesario realizar ninguna conversión. En los casos de conversión de tipo numérico a carácter, el tipo de datos numérico de Java se convierte en String. Por ejemplo, si se llama a setDouble con el valor "53" en una columna varchar(50), se producirá un valor de carácter "53" en esa columna de destino.
Convertido (y): Conversiones de un tipo numeric de Java a un tipo numeric del servidor subyacente que es menor. Esta conversión es normal y sigue las convenciones de conversión de SQL Server. La precisión siempre se trunca, nunca se redondea, y el desbordamiento lanza un error de conversión no admitida. Por ejemplo, si se usa updateDecimal con un valor de "1,9999" en una columna subyacente de enteros, el resultado es "1" en la columna destino; pero si se pasa "3000000000", el controlador lanzará un error.
Dependiente de datos (z): Conversiones de un tipo String de Java a un tipo de datos subyacente depende de las condiciones siguientes: el controlador envía el valor String a SQL Server y SQL Server realiza las conversiones si es necesario. Si la propiedad de conexión sendStringParametersAsUnicode se establece en true y el tipo de datos de subyacente es image, SQL Server no permite la conversión de nvarchar en image y genera una SQLServerException. Si sendStringParametersAsUnicode se establece en false y el tipo de datos subyacente de SQL Server es image,SQL Server permite la conversión de varchar en image y no genera ninguna excepción.
SQL Server realiza las conversiones y devuelve los errores a JDBC Driver cuando hay problemas.
Cuando el tipo de datos de columna de es XML, el valor de los datos debe ser un tipo XML válido. Cuando se llama a los métodos updateBytes, updateBinaryStream o updateBlob, el valor de los datos debe ser la representación de la cadena hexadecimal de los caracteres XML. Por ejemplo:
<hello>world</hello> = 0x3C68656C6C6F3E776F726C643C2F68656C6C6F3E
Tenga en cuenta que se necesita una marca de orden de bytes (BOM) si los caracteres XML están en codificaciones de caracteres específicos.
Conversiones en setObject
Nota
Microsoft JDBC Driver 4.2 (y versiones posteriores) para SQL Server admite JDBC 4.1 y 4.2. Para obtener más información sobre las conversiones y asignaciones de tipos de datos 4.1 y 4.2, consulte Cumplimiento de JDBC 4.1 con el controlador JDBC y Cumplimiento de JDBC 4.2 con el controlador JDBC, además de la información que se muestra a continuación.
Para los datos de tipo Java pasados a los métodos setObject(<Type>) de la clase SQLServerPreparedStatement, se aplican las conversiones siguientes.
El método setObject sin un tipo de destino especificado usará la asignación predeterminada. En el caso del tipo de datos String, si el valor supera la longitud deVARCHAR, se asigna a LONGVARCHAR. Del mismo modo, NVARCHAR se asigna a LONGNVARCHAR si el valor supera la longitud admitida de NVARCHAR. Lo mismo sucede para byte[]. Los valores mayores que VARBINARY pasan a ser LONGVARBINARY.
Los métodos setObject del controlador JDBC admiten tres categorías de conversiones:
Sin pérdidas (x): conversiones para los casos numéricos en los que el tipo de establecedor es igual o menor que el tipo de servidor subyacente. Por ejemplo, al llamar a setBigDecimal en una columna decimal del servidor subyacente, no es necesario realizar ninguna conversión. En los casos de conversión de tipo numérico a carácter, el tipo de datos numérico de Java se convierte en String. Por ejemplo, si se llama a setDouble con el valor "53" en una columna varchar(50), se producirá un valor de carácter "53" en esa columna de destino.
Convertido (y): Conversiones de un tipo numeric de Java a un tipo numeric del servidor subyacente que es menor. Esta conversión es normal y sigue las convenciones de conversión de SQL Server. La precisión siempre se trunca, nunca se redondea, y el desbordamiento lanza un error de conversión no admitida. Por ejemplo, si se usa updateDecimal con un valor de "1,9999" en una columna subyacente de enteros, el resultado es "1" en la columna destino; pero si se pasa "3000000000", el controlador lanzará un error.
Dependiente de datos (z): Conversiones de un tipo String de Java a un tipo de datos subyacente depende de las condiciones siguientes: el controlador envía el valor String a SQL Server y SQL Server realiza las conversiones si es necesario. Si la propiedad de conexión sendStringParametersAsUnicode se establece en true y el tipo de datos de subyacente es image, SQL Server no permite la conversión de nvarchar en image y genera una SQLServerException. Si sendStringParametersAsUnicode se establece en false y el tipo de datos subyacente de SQL Server es image,SQL Server permite la conversión de varchar en image y no genera ninguna excepción.
SQL Server realiza el grueso de las conversiones de establecimiento y devuelve errores a JDBC Driver cuando encuentra problemas. Las conversiones del lado cliente son la excepción y solamente se realizan en el caso de los valores date, time, timestamp, Boolean y String.
Cuando el tipo de datos de columna de es XML, el valor de los datos debe ser un tipo XML válido. Cuando se llama a los métodos setObject(byte[], SQLXML), setObject(inputStream, SQLXML) o setObject(Blob, SQLXML), el valor de los datos debería ser una representación de cadena hexadecimal de los caracteres XML. Por ejemplo:
<hello>world</hello> = 0x3C68656C6C6F3E776F726C643C2F68656C6C6F3E
Tenga en cuenta que se necesita una marca de orden de bytes (BOM) si los caracteres XML están en codificaciones de caracteres específicos.
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de