Páginas filhas
  • Alteração no mecanismo de execução de relatórios .Net

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Í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 ganho de performance na execução dos relatórios. Explicaremos como era o cenário antes e pôs alteração.

Informações
iconfalse
Deck of Cards
idExemplos
Card
idExemplo 1
labelCenário Anterior e Pós Melhoria
titleCenário Anterior e Pós Melhoria
Deck of Cards
idEstruturaAnterior
Card
idEstruturaAnterior
labelBandas do Relatório
titleBandas 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
idEstruturaAnterior
labelControles do Relatório
titleControles 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
iconfalse

(informação) 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
idEstruturaAnterior
labelFiltros do Relatório
titleFiltros 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
iconfalse

(informação) Neste caso temos uma parte do filtro ligado a tabela secundária da banda pai.

Card
idEstruturaAnterior
labelMecanismo de Execução Anterior
titleMecanismo 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:

  1. 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
iconfalse

(informação)  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".

  1. 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
iconfalse

(informação)  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
idEstruturaAnterior
labelMecanismo de Execução Pós Alteração
titleMecanismo 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
iconfalse

(informação)  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
iconfalse

(informação)  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.  (seleção)

Card
idExemplo 2
labelRelatórios após o ajuste
titleRelatórios após o ajuste
Deck of Cards
idEstruturaAnterior
Card
idEstruturaAnterior
labelBandas do Relatório
titleBandas 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
idEstruturaAnterior
labelControles do Relatório
titleControles 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
iconfalse

(informação) 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
idEstruturaAnterior
labelMecanismo de Execução Anterior
titleMecanismo 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:

  1. 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
iconfalse

(informação)  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".

  1. 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
iconfalse

(informação)  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.



Informações
iconfalse
Informações
iconfalse

Produto: Framework

Informações
iconfalse

Versão: 12.1.23 ou superiores

Informações
iconfalse

Processo: Execução de Relatórios

Informações
iconfalse
Informações
iconfalse

Status: Em andamento

Informações
iconfalse

Data:

Informações
iconfalse

Autores:

Aline Cristina Braz de Oliveira

Erlon Cesar Lima De Freitas

Gustavo Naves De Castro

Igor Macedo Cardoso

Lorena Roberta de Paiva Braga

LUCAS ANDRADE DE OLIVEIRA REIS

Renan Ramos Moura

TIAGO ANDRADE GOMES SILVEIRA

Wesley Avelino De Carvalho