Linha Microsiga Protheus

Árvore de páginas

CONTEÚDO

  1. Visão Geral
  2. Identificação 
  3. Fluxograma
  4. Possíveis Soluções
    1. Changequery;
    2. FWPreparedStatement;
  5. Gráfico 

01. Visão Geral

Estudo para propor uma melhoria na performance da rotina de Apuração de resultado(CTBA211).

02.Identificação

Analisando o log de um dos nossos clientes, identificamos que ocorre lentidão no processo de Apuração de Resultados, devido à quantidade de chamadas da função changequery desde a função SALDOCQ.

Na Apuração de Resultados a função changequery é chamada para gravar:

  • o arquivo temporário
  • cada tipo de moeda
  • o tipo de saldo
  • as contas contábeis

03. Fluxograma

IMPORTANTE

  • A função SALDOCT(X) chama a função SALDOCQ (CTBXSALA).
  • Se a apuração for por movimento será chamado a SALDOCT duas vezes, saldo anterior e saldo atual.


04. Possíveis Soluções 


a. Troca da função Changequery

Retirar a função changequery, realizando tratamento na montagem da query para utilizar o comando específico para cada banco (SQL, Oracle, Postgres, DB2). Assim executará a query diretamente.

Os comando que devem ser utilizados são:

  • Informex e Oraacle = NVL
  • Postgres e DB2 = COALESCE
  • SQL = ISNULL


b. Uso da função FWPreparedStatement

A função FWPreparedStatement representa um comando SQL pré compilado. 

Para utilizá-lo é necessário alterar todas as chamadas das origens SALDOCT(X) assim passaria a query correta e destruiria apos o fim da utilização da origem. 


Importante

Em testes,  alterando os parâmetros na montagem da query e chamando o FWPreparedStatement, funciona porém não da maneira correta, já que ao chamar a função SALDOCQ  está criando a query e destruindo-a, o que não constitui a melhor prática. 

Como utilizar - FWPreparedStatement


05. Gráfico 

Segue a baixo gráfico em segundos para as possíveis soluções. 


 

*Log tirado em uma base local com 29.607 registro de lançamento contábil.