Índice:

Índice

exclude	.*ndice:

Objetivo:

A partir da versão 12.1.23 implementamos uma melhoria na execução de relatórios do RM Reports que tende a evitar que relatórios possam gerar o que chamamos de "produto cartesiano". Esta melhoria poderá acarretar inconsistências em relatórios quando houverem bandas com mais de uma tabela e o relacionamento entre seus campos estiverem incorretos.

Detalhes da melhoria:

Esta alteração tende a obter obtém ganho de performance na execução dos relatórios. Explicaremos como era o cenário os cenários antes e pôs pós alteração.

Informações

icon	false

Deck of Cards

id	Exemplos

Exemplo 2Cenário Melhoria

Card

id	Exemplo 1
label	Cenário Anterior e Pós Melhoria
title	Exemplo 1Cenário Anterior e Pós Melhoria

Deck of Cards

id	EstruturaAnterior

Card

id	EstruturaAnterior
label	Bandas do Relatório
title	EstruturaAnteriorBandas do Relatório

No exemplo do cenário anterior utilizaremos a seguinte estrutura no relatório;

1) - Banda pai (Detalhe1) = Ligada na tabela PFUNC

1.1) - Banda filha (SubDetalhe1)= Ligada na tabela PFDEPEND

Card

id	EstruturaAnterior
label	Controles do Relatório
title	EstruturaAnteriorControles do Relatório

Em cada banda utilizamos os seguintes controles (no exemplo são utilizados controles de campo da base);

1) - Banda pai:

[PFUNC.CODCOLIGADA, PFUNC.CHAPA, PFUNC.SALARIO e PPESSOA.CPF]

Aviso

icon	false

Neste exemplo temos um controle da tabela principal ligado a outro controle da tabela secundária (PPESSOA.CPF).

1.1) - Banda filha:

[PFDEPEND.CODCOLIGADA e PFDEPENDE.NOME]

Card

id	EstruturaAnterior
label	Filtros do Relatório
title	EstruturaAnteriorFiltros do Relatório

Filtro do relatório utilizados na banda pai do relatório.

1) - Banda pai: PFUNC.CODCOLIGADA = 1

AND PPESSOA.CPF = '0027515458'

Aviso

icon	false

Neste caso temos uma parte do filtro ligado a tabela secundária da banda pai.

Card

id	EstruturaAnterior
label	Mecanismo de Execução Anterior
title	Mecanismo de Execução Anterior

Quando o relatório é executado, o mecanismo de execução vai gerar duas sentenças sql’s dinamicamente baseadas nas configurações das bandas e controles.

Nesse exemplo serão geradas duas sentenças sql’s:

A) - Primeira sentença: relacionada a banda pai;

SELECT PFUNC.CODCOLIGADA,
PFUNC.CHAPA,
PFUNC.SALARIO,
PPESSOA.CPF
FROM PFUNC
LEFT OUTER JOIN PPESSOA (NOLOCK) ON (PFUNC.CODPESSOA = PPESSOA.CODIGO)
WHERE PFUNC.CODCOLIGADA = 1
AND PPESSOA.CPF = '0015154515'

Aviso

icon	false

Na sentença acima, o mecanismo adiciona uma clausula (Left Outer Join) para tabela PPESSOA. Isso ocorre devido ao controle "CPF" existente na banda pai pois o mesmo não existe na tabela principal da banda "PFUNC".

B) - Segunda sentença: relacionada a banda filha:

SELECT PFDEPEND.CODCOLIGADA,
PFDEPENDE.NOME
FROM PFDEPEND
INNER JOIN PFUNC (NOLOCK) ON (PFUNC.CODCOLIGADA = PFDEPEND.CODCOLIGADA
AND PFUNC.CHAPA = PFDEPEND.CHAPA)
WHERE PFUNC.CODCOLIGADA = 1

Aviso

icon	false

Perceba que a query acima retornará todos os dependentes de todos os funcionários da Coligada 1. Nesse caso, teremos considerado consumo de memória e performance.

Card

id

label
EstruturaAnterior

Mecanismo de Execução Pós

title

Exemplo 2

Alteração
title	Mecanismo de Execução Pós Alteração

Primeira sentença: Relacionada a banda pai;

SELECT PFUNC.CODCOLIGADA,
PFUNC.CHAPA,
PFUNC.SALARIO,
PPESSOA.CPF
FROM PFUNC
LEFT OUTER JOIN PPESSOA (NOLOCK) ON (PFUNC.CODPESSOA = PPESSOA.CODIGO)
WHERE PFUNC.CODCOLIGADA = 1
AND PPESSOA.CPF = '0015154515'

Aviso

icon	false

Nada muda em relação à query executada atualmente.

Segunda sentença: Relacionada a banda filha;

SELECT PFDEPEND.CODCOLIGADA,
PFDEPENDE.NOME
FROM PFDEPEND
INNER JOIN PFUNC (NOLOCK) ON (PFUNC.CODCOLIGADA = PFDEPEND.CODCOLIGADA
AND PFUNC.CHAPA = PFDEPEND.CHAPA)
LEFT OUTER JOIN PPESSOA (NOLOCK) ON (PFUNC.CODCOLIGADA = PPESSOA.CODCOLIGADA
AND PFUNC.CODPESSOA = PPESSOA.CODIGO)
WHERE PFUNC.CODCOLIGADA = 1
AND PPESSOA.CPF = '0015154515'

Aviso

icon	false

Nesta execução, a query de Dependentes retornará somente dependentes ligados ao Funcionário com CPF "0015154515"

Em resumo com a passagem da clausula "LEFT OUTER JOIN PPESSOA" da query ligada a banda pai para a query ligada a banda filha, somente os dependentes que participam da listagem do relatório serão recuperados da base. Isso melhorará consideravelmente a performance e memória do Host.

Depois do ajuste, percebermos um cenário que poderá trazer dados desnecessários no relatório, ficando a sensação de inconsistência no RM Reports.

Informações

icon	false

Deck of Cards

id	Exemplos

Card

id	Exemplo 2
label	Relatórios mapeados depois do ajuste
title	Relatórios após o ajuste

Deck of Cards

id	DepoisdaAlteracao

Card

id	DepoisdaAlteracao

Deck of Cards

id	EstruturaAnterior

Card

EstruturaAnterior

id	EstruturaAnterior
label	Bandas do Relatório
title	Bandas do Relatório

No exemplo utilizaremos a seguinte estrutura no relatório;

1) - Banda pai (Detalhe1) = Ligada na tabela "PFUNC"

1.1) Banda filha (SubDetalhe1)= Ligada na tabela "PFDEPEND"

Card

EstruturaAnterior

id	EstruturaAnteriorDepoisdaAlteracao
label	Controles do Relatório
title		Controles do Relatório

Em cada banda contem os seguintes controles (utilizados controles de campo da base);

1) - Banda pai:
[PFUNC.CODCOLIGADA, PFUNC.CHAPA, PFUNC.SALARIO, ABATFUN.DATA]

Aviso

icon	false

Neste exemplo temos um controle da tabela principal ligado a outro controle da tabela secundária (ABATFUN.DATA).

1.1) - Banda filha: [PFDEPEND.CODCOLIGADA, PFDEPENDE.NOME]

Card

EstruturaAnterior

id	EstruturaAnteriorDepoisdaAlteracao
label	Filtros do Relatório	title	Mecanismo de Execução Errônea
title	Mecanismo de Execução Errônea

Quando o relatório é executado, o mecanismo de execução vai gerar duas sentenças sql’s dinamicamente baseadas nas configurações das bandas e controles. Nesse caso serão geradas duas sentenças sql.

Primeira sentença: Relacionada a banda pai;

SELECT PFUNC.CODCOLIGADA,
PFUNC.CHAPA,
PFUNC.SALARIO,
ABATFUN.DATA
FROM PFUNC
LEFT OUTER JOIN ABATFUN (NOLOCK) ON (PFUNC.CODCOLIGADA = ABATFUN.CODCOLIGADA
AND PFUNC.CHAPA = ABATFUN.CHAPA)
WHERE PFUNC.CODCOLIGADA = 1
AND ABATFUN.DATA < :DATAATUAL

Aviso

icon	false

Nada muda em relação à query que será executada depois da melhoria.

Segunda sentença: Relacionada a banda filha;

SELECT PFDEPEND.CODCOLIGADA,
PFDEPENDE.NOME
FROM PFDEPEND
INNER JOIN PFUNC (NOLOCK) ON (PFUNC.CODCOLIGADA = PFDEPEND.CODCOLIGADA
AND PFUNC.CHAPA = PFDEPEND.CHAPA)
LEFT OUTER JOIN ABATFUN (NOLOCK) ON (PFUNC.CODCOLIGADA = ABATFUN.CODCOLIGADA
AND PFUNC.CHAPA = ABATFUN.CHAPA)
WHERE PFUNC.CODCOLIGADA = 1
AND ABATFUN.DATA < :DATAATUAL

Neste cenário, a primeira sql, ao ser executada, retornará dados repetidos para o funcionário, visto que, existirá várias batidas para um único funcionário. Isso gera o que chamamos de "produto cartesiano". A query de dependentes retornará os dependentes ligados ao funcionário que possua batidas < que "DATAATUAL", gerando também, produto cartesiano para os dependentes.Sendo assim, ao gerar o relatório, na banda de dependentes, aparecerá vários dependentes repetidos de acordo com as batidas de um determinado funcionário.

Image Added