Saltar al contenido

¡Transforma tus conexiones en dinero para el final del año con nuestro nuevo Programa de Indicación de Clientes! Descubre más

✕

Esta documentación es para la versión 4 y posteriores de App Builder, el nuevo nombre de Vinyl. Accede a la documentación de Vinyl aquí.

✕

Literales de cadena mvSQL en Jitterbit App Builder

El estándar SQL define dos tipos de cadenas de caracteres, cada uno con su propia sintaxis literal.

  • ANSI
  • Nacional

Las cadenas de caracteres ANSI representan ASCII y otros conjuntos de caracteres de un solo byte, como EBCDIC en DB2/i.

Las cadenas de caracteres nacionales representan conjuntos de caracteres multibyte como Unicode.

El estándar SQL define una sintaxis literal independiente para cada tipo de cadena de caracteres. La sintaxis para una cadena literal ANSI es:

'Aristotle''s quotes'Tenga en cuenta que las comillas simples insertadas en el literal de cadena se escapan duplicándolas.

La sintaxis de un literal de cadena nacional es:

N'Aristotle''s quotes'

mvSQL admite la sintaxis estándar SQL para literales de cadena de caracteres ANSI y nacionales.

Nota

El uso de una sintaxis literal SQL incorrecta puede provocar una degradación significativa del rendimiento. Dada una columna que almacena datos en un conjunto de caracteres ANSI, una condición de búsqueda que contenga una literal de cadena nacional no aprovechará ningún índice y forzará la conversión de los valores de la columna.

Algunos motores de bases de datos, como Oracle, no admiten conversiones implícitas entre conjuntos de caracteres. El uso de la sintaxis literal de cadena de caracteres adecuada evitará errores y la necesidad de conversiones explícitas.

Soporte del proveedor

A menos que se indique lo contrario, las cadenas de caracteres literales ANSI y nacionales se asignan directamente a su equivalente nativo.

MySQL

MySQL no define una sintaxis independiente para los literales de cadena de caracteres ANSI y nacionales. En MySQL, se asume que el literal de cadena se codifica con el conjunto de caracteres de la conexión. Esto significa que la codificación puede variar según la configuración de la conexión. Si la conexión utiliza una codificación ANSI (como la codificación latin1 predeterminada), se asume que todas las cadenas son ANSI.

Nota

App Builder configura las conexiones MySQL con el conjunto de caracteres UTF-8 de forma predeterminada. Utilice el parámetro CharSet para cambiar el conjunto de caracteres de la conexión MySQL. Por ejemplo, para usar el conjunto de caracteres ASCII predeterminado de MySQL, añada CharSet=latin1 a la configuración avanzada.

MySQL admite introductores de conjuntos de caracteres. El "introductor" es un prefijo que se añade al principio del valor literal de la cadena. Este prefijo indica el conjunto de caracteres de la cadena. App Builder utiliza introductores de conjuntos de caracteres para garantizar que los datos Unicode se puedan codificar en literales de cadena, independientemente de la configuración de la conexión. Por el contrario, si la conexión utiliza el conjunto de caracteres UTF-8, el introductor de conjuntos de caracteres garantiza que los datos ASCII se transmitan al servidor como ASCII, evitando conversiones problemáticas.

En la práctica, esto significa que una cadena literal de caracteres ANSI mvSQL se traducirá a:

_latin1'Aristotle''s quotes'Una cadena literal de caracteres mvSQL National se traducirá a la sintaxis de MySQL como:

_utf8'Aristotle''s quotes'

MySQL no define tipos de datos de almacenamiento separados para los tipos de caracteres ANSI y nacionales. En su lugar, todos los tipos de cadena se almacenan en un tipo de dato común. El conjunto de caracteres determina cómo se almacenan los datos. App Builder asigna columnas de caracteres MySQL con un conjunto de caracteres Unicode (utf-8) al tipo de cadena de caracteres nacional correspondiente, independiente del proveedor (p. ej., NCHAR o NVARCHAR).

DB2/i

Al igual que MySQL, DB2/i no tiene tipos de datos separados para cadenas de caracteres ANSI y nacionales. En su lugar, el CCSID determina la codificación. El CCSID es un entero de 16 bits sin signo. Es similar al LCID de Windows.

Al igual que con MySQL, App Builder inspecciona el CCSID para asignarlo correctamente de un tipo de carácter DB2/i (p. ej., VARCHAR) a un tipo de dato independiente del proveedor de App Builder(p. ej., NVARCHAR). Los siguientes CCSID se asignarán al tipo de dato NVARCHAR:

  • 1200 - UTF-16
  • 1208 - UTF-8
  • 13488 - UCS-2

Por el contrario, al crear columnas con un tipo de dato de carácter nacional, App Builder establece explícitamente el CCSID. En concreto, App Builder establece el CCSID en 1208 (UTF-8).

Finalmente, DB2/i no necesita una sintaxis independiente para las cadenas de caracteres ANSI y nacionales. Por lo tanto, se utiliza la misma sintaxis para ambas.

Fuentes de datos que no son RDBMS

Los literales de cadena nacionales mvSQL no son compatibles con fuentes de datos que no sean RDBMS, como REST y Salesforce, etc.

Lectura adicional

https://learn.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support

https://docs.microsoft.com/en-us/sql/t-sql/data-types/constants-transact-sql

https://dev.mysql.com/doc/refman/8.0/en/charset-introducer.html