Ir para o conteúdo

Transforme as suas conexões em um bônus de fim de ano com o nosso novo Programa de Indicação de Clientes! Saiba mais

Esta documentação é para a versão 4 e posterior do App Builder, o novo nome do Vinyl. Acesse a documentação do Vinyl aqui.

Literais de string mvSQL no Jitterbit App Builder

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

  • ANSI
  • Nacional

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

Cadeias de caracteres nacionais representam conjuntos de caracteres multibyte, como Unicode.

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

'Aristotle''s quotes'

Observe que aspas simples incorporadas dentro do literal de string são escapadas dobrando as aspas simples.

A sintaxe para um literal de string nacional é:

N'Aristotle''s quotes'

mvSQL suporta a sintaxe SQL Standard para literais de string de caracteres ANSI e National.

Nota

Usar a sintaxe literal SQL errada pode resultar em degradação significativa do desempenho. Dada uma coluna que armazena dados em um conjunto de caracteres ANSI, uma condição de pesquisa contendo um literal de string National não aproveitará nenhum índice e forçará uma conversão de valores de coluna.

Alguns mecanismos de banco de dados, como o Oracle, não suportam conversões implícitas entre conjuntos de caracteres. Usar a sintaxe literal de string de caracteres apropriada evitará erros e eliminará a necessidade de conversões explícitas.

Suporte ao fornecedor

A menos que documentado de outra forma, literais de string de caracteres ANSI e nacionais são mapeados diretamente para o equivalente do fornecedor nativo.

MySQL

O MySQL não define uma sintaxe separada para literais de string de caracteres ANSI e National. 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 de conexão. Se a conexão usar uma codificação ANSI (como a codificação latin1 padrão), todas as strings serão assumidas como ANSI.

Nota

O App Builder define as conexões MySQL como padrão para o conjunto de caracteres UTF-8. Use o parâmetro CharSet para alterar o conjunto de caracteres de conexão MySQL. Por exemplo, para usar o conjunto de caracteres ASCII padrão do MySQL, adicione CharSet=latin1 às configurações avançadas.

O MySQL suporta introdutores de conjunto de caracteres. O "introdutor" é um prefixo adicionado ao início do valor literal da string. O prefixo indica o conjunto de caracteres da string. O App Builder usa introdutores 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 introdutor de conjunto de caracteres garante que os dados ASCII sejam passados para o servidor como ASCII, evitando conversões problemáticas.

Na prática, isso significa que uma literal de string de caracteres ANSI mvSQL será traduzida para:

_latin1'Aristotle''s quotes'

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

_utf8'Aristotle''s quotes'

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

DB2/i

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

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

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

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

Por fim, o DB2/i não precisa ter uma sintaxe separada para strings de caracteres ANSI e National. Portanto, a mesma sintaxe é usada para ambas.

Fontes de dados não RDBMS

Literais de string nacionais 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