Descripción de las conversiones de tipos de datos

Para facilitar la conversión de tipo de datos del lenguaje de programación Java a tipos de datos de SQL Server, el controlador JDBC de Microsoft SQL Server proporciona las conversiones de tipos de datos que requiere la especificación JDBC. Para mejorar la flexibilidad, todos los tipos son convertibles entre los tipos de datos Object, String y byte[].

Conversiones de métodos de captador

Según los tipos de datos SQL Server, el siguiente cuadro contiene el mapa de conversión del controlador JDBC para los métodos get<Type>() de la clase SQLServerResultSet, así como las conversiones no 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 un int, pero si el valor subyacente es "xyz" o "3000000000", se genera un error.

Si se llama a getString en un tipo de datos de columna binary, varbinary, varbinary(max) o image, el valor se devuelve como un valor de cadena hexadecimal.

Conversiones de métodos de actualización

Para los tipos de datos de 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 actualización 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.

Cuado se llama a updateString en un tipo de datos de columna binary, varbinary, varbinary(max) o image, controla el valor como un valor de cadena hexadecimal.

Cuando el tipo de datos de columna de SQL Server es XML, el valor de los datos debe ser un 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 decimal 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 establecedor

Para los tipos de datos de 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 de VARCHAR, se asigna a LONGVARCHAR. Similarmente NVARCHAR se asigna a LONGNVARCHAR, si el valor supera la longitud admitida de NVARCHAR. Lo mismo sucede para byte[]. Los valores mayores que VARBINARY se vuelven 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 numeric 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 utiliza 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 de "3000000000", el controlador lanzará un error.
• Dependiente de datos (z): las conversiones de un tipo String de Java al tipo de datos de SQL Server subyacente dependen de las siguientes condiciones: el controlador envía el valor String a SQL Server y, si fuera necesario, SQL Server realizará las conversiones. Si sendStringParametersAsUnicode se configura en TRUE y el tipo de datos SQL Server subyacente es image, SQL Server no permite la conversión de nvarchar en image y genera una excepción SQLServerException. Si sendStringParametersAsUnicode se configura en false y el tipo de datos SQL Server subyacente es image, SQL Server permite la conversión de varchar en image y no genera una excepción.

SQL Server realiza las conversiones y devuelve los errores al controlador JDBC cuando hay problemas.

Cuando el tipo de datos de columna de SQL Server es XML, el valor de los datos debe ser un 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 decimal 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

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 de VARCHAR, se asigna a LONGVARCHAR. Similarmente NVARCHAR se asigna a LONGNVARCHAR, si el valor supera la longitud admitida de NVARCHAR. Lo mismo sucede para byte[]. Los valores mayores que VARBINARY se vuelven 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 numeric 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 utiliza 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 de "3000000000", el controlador lanzará un error.
• Dependiente de datos (z): las conversiones de un tipo String de Java al tipo de datos de SQL Server subyacente dependen de las siguientes condiciones: el controlador envía el valor String a SQL Server y, si fuera necesario, SQL Server realizará las conversiones. Si sendStringParametersAsUnicode se configura en TRUE y el tipo de datos SQL Server subyacente es image, SQL Server no permite la conversión de nvarchar en image y genera una excepción SQLServerException. Si sendStringParametersAsUnicode se configura en FALSE y el tipo de datos SQL Server subyacente es image, SQL Server permite la conversión de varchar en image y no genera una excepción.

SQL Server realiza el grueso de las conversiones de establecimiento y devuelve errores al controlador JDBC 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 SQL Server es XML, el valor de los datos debe ser un 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.

Vea también

Otros recursos

Describir los tipos de datos del controlador JDBC