Suspeita de Bug - Interpretação numérica de dado string
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 ?
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.
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.
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á.
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).
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.
