Versões comparadas

Chave

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

Produto

:

TOTVS Framework                                                          

Processo

:

Filtro de Action

Subprocesso

:

Utilizando filtro com SQL

Data da publicação

:

10/06/2015

Objetivo

Ao utilizar um filtro de visão que possua como parâmetro o operador IN(SQL) ou NOT IN (SQL), corre-se o risco de tornar a visualização da tela extremamente lenta. Este fato ocorre devido a independência das Sentenças geradas na execução do banco de dados.

Toda visão ao ser carregada, executa uma Consulta no banco de dados. Quando um destes dois operadores são utilizados, uma Sentença SQL é montada. A Sentença que é gerada ao abrir a visão é mesclada com a Sentença inserida no operador do filtro para assim então, executar a Consulta no banco de dados.

Devido ao fato das sentenças (da visão e a do operador SQL) não possuírem nenhuma conexão, o plano de execução gerado pelo SGBD não será o adequado e por esse fato ocorrem casos de extrema lentidão quando usuários desejam executar este tipo de processo.

Para resolver o problema, é necessário adaptar a Consulta SQL utilizada com o operador escolhido, otimizando-a de forma que exista uma conexão entre as Sentenças SQL.

Caso Inadequado

Este é o caso Inadequado e comumente utilizado

Deck of Cards
idDeck
Card
labelPasso 1

Acesse “Serviços Globais | Gestão | Visões de Dados” e insira a seguinte consulta SQL:

Card
labelPasso 2

Agora acesse “Serviços Globais | Administração | Coligadas” e selecione “Novo filtro”:

Card
labelPasso 3

Na edição do filtro selecione o campo Código, o operador IN(SQL) e a consulta criada anteriormente (SUBQUERY):

Card
labelPasso 4

Este modo é inadequado pois não possui conexão com a Sentença da action. Para moldelo de exemplo, considere a imagem abaixo como a Sentença que é gerada. Em negrito é a sentença gerada pela action e sublinhado a Sentença adicionada pelo filtro. Destacado em vermelho, está a linha que pode ser otimizada. Percebe-se que a “SUBQUERY” não possui conexão com a Sentença principal, isso torna a consulta do SGBD muito mais carregada e lenta.

 

 

 

Caso Adequado

Este é o caso Adequado e recomendado para melhor performance do sistema.

 

Desck2
Deck of Cards
id
Deck2
Card
labelPasso 1

Acesse “Serviços Globais | Gestão | Visões de Dados” e insira a seguinte consulta SQL:

Image Modified

Ao clicar em salvar, o sistema ira retornar uma mensagem de aviso pois ela não possui a tabela GCOLIGADA como parâmetro, clique em Sim e salve a consulta

.

:

Image Modified

Card
labelPasso 2

Agora acesse “Serviços Globais | Administração | Coligadas” e selecione “Novo filtro”:

Image Modified

Card
labelPasso 3

Na edição do filtro selecione o campo Código, o operador IN(SQL) e a consulta criada anteriormente (SUBQUERY):

Image Modified

Card
labelPasso 4

Este modo é o mais adequado pois possui conexão com a Sentença da action. Para modelo de exemplo, considere a imagem abaixo como a Sentença que é gerada. Em negrito é a sentença gerada pela action e sublinhado a Sentença adicionada pelo filtro. Destacado em vermelho, está a linha que foi otimizada para proporcionar uma melhor performance a Sentença, consequentemente uma resposta melhor do sistema ao se utilizar tais tipos de filtro

:

.

Image Modified