mvSQL literais de string no Jitterbit App Builder

O padrão SQL define dois tipos de string de caracteres, cada um com sua própria sintaxe literal.

• ANSI
• Nacional

Strings de caracteres ANSI representam ASCII e outros conjuntos de caracteres de byte único, como EBCDIC no DB2/i.

Strings de caracteres nacionais representam conjuntos de caracteres de múltiplos bytes, como Unicode.

O padrão SQL define uma sintaxe literal separada para cada tipo de string de caracteres. A sintaxe para um literal de string ANSI é:

'Citações de Aristóteles'

Note que as aspas simples incorporadas dentro do literal de string são escapadas duplicando a aspa simples.

A sintaxe para um literal de string Nacional é:

N'Citações de Aristóteles'

mvSQL suporta a sintaxe do padrão SQL para literais de string de caracteres ANSI e Nacionais.

Suporte do fornecedor

Salvo documentação em contrário, literais de string de caracteres ANSI e Nacionais são mapeados diretamente para o equivalente nativo do fornecedor.

MySQL

O MySQL não define uma sintaxe separada para literais de string de caracteres ANSI e Nacionais. No MySQL, o literal de string é assumido como codificado usando o conjunto de caracteres da conexão. Isso significa que a codificação pode variar com base nas configurações da conexão. Se a conexão usar uma codificação ANSI (como a codificação padrão latin1), então todas as strings são assumidas como ANSI.

MySQL suporta introduzidores de conjunto de caracteres. O "introduzidor" é um prefixo adicionado ao início do valor literal da string. O prefixo indica o conjunto de caracteres da string. O App Builder utiliza introduzidores de conjunto de caracteres para garantir que dados Unicode possam ser codificados em literais de string, independentemente das configurações de conexão. Por outro lado, se a conexão usar o conjunto de caracteres UTF-8, o introduzidor de conjunto de caracteres garante que dados ASCII sejam enviados ao servidor como ASCII, evitando conversões problemáticas.

Na prática, isso significa que um literal de string de caracteres ANSI do mvSQL será traduzido para:

_latin1'Aristotle''s quotes'

Um literal de string de caracteres nacionais do mvSQL será traduzido para a sintaxe do MySQL como:

_utf8'Aristotle''s quotes'

MySQL não define tipos de dados de armazenamento separados para tipos de caracteres ANSI e Nacionais. Em vez disso, todos os tipos de string são armazenados em um tipo de dado comum. O conjunto de caracteres determina como os dados são armazenados. O App Builder mapeia colunas de caracteres do MySQL com um conjunto de caracteres Unicode (utf8) para o tipo de string nacional correspondente e neutro em relação ao fornecedor (por exemplo, NCHAR ou NVARCHAR).

DB2/i

Assim como o MySQL, o DB2/i não possui tipos de dados separados para strings de caracteres ANSI e Nacionais. Em vez disso, o CCSID determina a codificação. O CCSID é um inteiro não assinado de 16 bits. É semelhante em natureza ao LCID do Windows.

Assim como no MySQL, o App Builder inspeciona o CCSID para mapear corretamente de um tipo de caractere DB2/i (por exemplo, VARCHAR) para um tipo de dado neutro em relação ao fornecedor do App Builder (por exemplo, NVARCHAR). Os seguintes CCSIDs serão mapeados para o tipo de dado NVARCHAR:

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

Por outro lado, ao criar colunas com um tipo de dado de caractere nacional, o App Builder define explicitamente o CCSID. Especificamente, o App Builder define o CCSID como 1208 (UTF-8).

Finalmente, o DB2/i não precisa ter uma sintaxe separada para strings de caracteres ANSI e Nacionais. Portanto, a mesma sintaxe é usada para ambos.

Fontes de dados não-RDBMS

Literais de string nacionais do mvSQL não são suportados para fontes de dados não-RDBMS, como REST e Salesforce, etc.

Leitura 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