topic Suspeita de Bug - Interpretação numérica de dado string in Archived Groups

Suspeita de Bug - Interpretação numérica de dado string

Anonymous — Wed, 23 Jul 2025 14:48:52 GMT

Me deparei com um problema de datatype que acredito ser um bug do QlikView.

Em meu DW, tenho uma coluna [CentroCusto] com 11 caracteres, dividida no formato AAA.BB.CC.DD.EE, onde:

AAA = id. cliente

BB = id. filial

CC = id. segmento de negócio

DD = id. serviço

EE = id. especificação do serviço

Exemplos de Centros de Custo:

"16226110000"

"162261100F2"

Todas as divisões acima são alfanuméricas.

Ainda bem que no mesmo DW eu carreguei paralelamente os 5 componentes do centro de custo (colunas: cliente,filial,segmento,serviço,especificação). A seguir, vocês entenderão o motivo.

No aplicativo descobri uma distorção nos números não justificada no DW e no ETL. Descobri que o Qlikview interpretou a dimensão centro de custo "162261100F2" como "16226110000", isto é, como o Centro de Custo começou com números mas terminou com uma letra no penúltimo caractere, o QlikView "trocou" os dois últimos caracteres por "00" conflitando assim com o centro de custo final "00" que por sua vez existe na base. Como resultado, produto cartesiano e duplicidade de valores nas expressões que dependem do centro de custo.

Tentativas mal sucedidas de solucionar o problema:

* Certifiquei-me que no DW havia somente um centro de Custo "16226110000" e outro "162261100F2";

* No ETL, comentei todos os Joins relativos ao centro de custo, bem como carreguei somente o centro de custo "16226110000", resultando em duplicidade de linhas;

* Tentei iniciar o centro de custo com uma letra;

* Tentei a function TEXT sobre o Centro de Custo (11 caracteres alfanuméricos) com o propósito de forçar a interpretação do dado como texto;

Ação que resolveu o problema:

* Compus o centro de custo concatenando seus componentes e o submeti a função TEXT() assim:

// ETL, aplicativo de tratamento

CentroCusto:

LOAD text(CLI&FIL&SEG&SER&ESP) as %CentroCustoID,

text(CLI&FIL&SEG&SER&ESP) as CentroCustoCodigo,

DESCR as CentroCustoNome,

CLI as ClienteCodigo,

FIL as FilialCodigo,

SEG as SegmentoCodigo,

SER as ServicoCodigo,

ESP as EspecificacaoCodigo

FROM $(vODSDir)\ODS_$(vNomeSistema)_CCU.qvd (qvd);

SET vNomeQVD = '$(vNomeSistema)_DIM_CentroCusto';

STORE CentroCusto INTO $(vDWHDir)\DW_$(vNomeQVD).qvd;

Com base no exposto, alguém sabe como contornar essa situação sem recorrer a esses artifícios que mencionei ?

Re: Suspeita de Bug - Interpretação numérica de dado string

fosuzuki — Thu, 21 Nov 2013 17:42:53 GMT

Evandro,

Qual versão do QV vc está usando? Fiz dois testes no 11.2SR3, fazendo carga de Inline e de XLS, e nenhum deles deu erro.

Pode enviar um QVVW de exemplo demonstrando o problema?

Re: Re: Suspeita de Bug - Interpretação numérica de dado string

Anonymous — Thu, 21 Nov 2013 19:32:55 GMT

Fernando,

Minha versão já é a 11.20SR4.

Segue anexo o QVW utilizando o campo COD do centro de custo com 11 caracteres (nativo da base, sem o tratamento exposto no blog). Veja no [Ctrl T] que o centro de custo 16226110000 existe na base assim como o 162261100D2. Veja evidência no campo CentroCustoCodNome onde o QV intepreta no campo COD o 162261100D2 como 16226110000.

Obrigado!

Evandro

Re: Re: Re: Suspeita de Bug - Interpretação numérica de dado string

fosuzuki — Thu, 21 Nov 2013 20:40:18 GMT

Evandro,

Com o "F2" não tinha conseguido replicar o problema, mas com o "D2" sim.

Não entendi muito bem o porque, mas aparentemente o "D2" no final é convertido para "00". Fiz um teste com "D5" e aparece "00000" no lugar do "D5". Acho que o QV está entendendo que quando encontrar "Dx", trocar por "x zeros".

Mas eu acho que vc consegue contornar o problema se mexer no QVW que gera o arquivo XXPRC.qvd, porque aparentemente esse QVD já está com esse problema. Tenta colocar a formatação de texto nesse extrator que acho que resolverá.

Re: Suspeita de Bug - Interpretação numérica de dado string

Anonymous — Fri, 22 Nov 2013 10:52:45 GMT

Fernando

Bom dia. Realmente, dá certo formatar o dado como texto no extrator, porém só dá certo se eu o fizer concatenando os códigos que compoem do Centro de Custo, ou seja, assim: text(CLI&FIL&SEG&SER&ESP). Se eu formatar diretamente o campo (text(COD)), o problema da troca por zeros volta a ocorrer, mesmo que eu force uma letra antes do código (Right(text('X'&COD),11).

Obrigado pela breve resposta e interesse

Evandro

Re: Re: Suspeita de Bug - Interpretação numérica de dado string

fosuzuki — Sat, 23 Nov 2013 16:28:26 GMT

Evandro,

vc pode enviar o script do qvw extrator? Talvez eu consiga te ajudar.

Re: Suspeita de Bug - Interpretação numérica de dado string

s_uhlig — Sun, 24 Nov 2013 22:26:42 GMT

Hi Evandro,

there is a new "feature" introduced in QV 11.20, which interpretes "D" as a symbol for exponential notation beside "E".

Therefore '1D1'='1E1' (!!!) and 162261100D2=162261100*100=16226110000.

QV 11.2 SR5 will introduce the Variable "ExponentNumberNotation" to selectively disable this behavior.

There exists a patch for SR3 and SR4 - please ask support.

You should also be able to load the critical fields explicitly as text (text(..)).

Regards

Sven

Re: Suspeita de Bug - Interpretação numérica de dado string

fosuzuki — Mon, 25 Nov 2013 16:41:43 GMT

Hi Sven,

Thanks for giving an answer to my suspicion.

Are you from QlikTech? Where did you find these information??

Regards from Brazil,

Fernando

Re: Suspeita de Bug - Interpretação numérica de dado string

s_uhlig — Mon, 25 Nov 2013 16:56:00 GMT

Hi Fernando,

no, I'm not, but I had the same issue little time ago and got this answer to my bug report.

I had it on my list to post it here, but didn't found the time - Sorry.

Regards

Sven

Re: Suspeita de Bug - Interpretação numérica de dado string

fosuzuki — Tue, 17 Dec 2013 11:57:18 GMT

Hi Sven and Evandro,

just a follow-up:

QT released v11.2 SR5 and now there is a variable to correctly address this problem:

Bug: 65030 Mixed Values with values like 1E4 are mismatched

When loading text fields QlikView has always tried to interpret numeric values and load them as numeric, not text. Due to two different bugs the behavior of QlikView interpretation of exponential numbers, nnnEn or nnnDn, has changed between releases. The safest way to make sure you get the interpretation you like has always been to cast the specific fields to the right type in the script.

For customers with many old scripts affected by the behavior change, it has been decided to implement a solution which allows a small degree of control of how QlikView will interpret text fields at script level. A script variable 'ExponentNumberNotation' has been introduced. It can be assigned:

0 meaning neither 1.23E6 nor 1.23D6 is interpreted as an exponential number

1 meaning 1.23E6 but not 1.23D6 is interpreted as an exponential number

2 meaning both 1.23E6 and 1.23D6 are interpreted as an exponential number

If not assigned a value in the script, 1 will be the default value.