Consulta mais rápida

[Ricardo Sales Ribeiro]

Boa Tarde
Amigos!

Estou mais uma vez precisando de ajuda.
Tenho um pequeno sistema, que montei esta semana, bem básico, então veremos:

Um Cadastro de Os, Ordem de serviços, onde tem:
Nro da Os
Data
Código do técnico
Status

Status, é, C, Cancelada, P, Pendente, R Revisita, e F, Finalizada ok.

O Sistema é só para cadastrar as os´s e depois dar baixa, tipo localizar a Os e colocar uma das opções de status.

Diariamente, são digitadas 300 ou 400 os´s, e já estar ficando lento, são 6 usuários, adicionando e baixando os´s ao mesmo tempo, crie índice pela os, mas estar ficando lento para localizar as os´s e baixar.

O patrão estar chiando, pela lentidão, gostaria de opinião de vcs de como montar esse sisteminha para rodar direitinho, sugestões.

Desde já agradeço.

[rochinha]

Amiguinho,

Tudo depende de como voce codificou o aplicativo.

- Você usa índices?
- Você usa filtragem com SER FILTER?
- Seus comandos de localização são LOCATE?

Se você respondeu SIM para todas as perguntas acima encontrou o problema.

Os índices são arquivos auxiliares aos DBFs que permitem colocar ordem nos registros, desta forma, a partir de funções como dbSeek() é possivel se posicionar em um determinado registro de forma instantânea.

O uso de SET FILTER pode diminuir a lista de registros que tenham uma similaridade ou algo em comum, como por exemplo o código de cliente em registros de vendas. O problema com o uso deste comando é no momento em que temos muitos registros no DBF. A lentidão aparece.

Os comandos LOCATE são similares ao SEEK, mas não precisam de uso de índices o que o torna lento quando existem muitos registros na tabela.

Portanto, nos dê mais subsídios sobre o seu problema para que após a análise possamos dar soluções.

[Ricardo Sales Ribeiro]

Boa Tarde
Caro Rochinha.
Dando mais informações sobre meu sisteminha.

Eu usu sim indices,

Use OrdSer
Inde On NroOds To OrdSerCd
Inde On CodEqu+DtoC(DatEmi)+NroOds To OrdSerEq

Faço a procura usando Locate, tanto pelo Numero da Os como para localizar por tecnico e data

Na consulta uso um dbedit
Que estar organizado pelo segundo indice, por tecnico, dentro do tecnico por data e dentro da data por Os.

Na localização por Os, usando ou não o indice, com o locate, ta demorando muito, são quase 800 lançamentos dia, são
cinco usuarios lançando e ao mesmo tempo baixando, ta lento, não estar agilizando o serviço.
O sistema fica no servidor, o executavel, nas estações fica os atalhos, a rede é wi fi, não é cabeada, não sei se isso contribui para lentidão.

No servidor em loco, é rápido, mas é só um usuário.
Preciso agilizar, por favor me ajudem.

Atenciosamente

[acelconsultoria]

Ricardo,

Se você está utilizando o Clipper 5.3, poderá utilizar o SET SCOPE.

Eu tive um caso parecido, com uma tabela onde eu tinha que filtrar por data e por nome de cliente. Ficava muito lento, usando apenas o SET FILTER pra tudo e mostrando no DBEDIT.

Criei um índice pra data, e utilizei o SET SCOPE para apenas obter o intervalo de datas desejado. E em seguida o SET FILTER para obter o cliente desejado. Combinando os dois assim, ficou muito mais rápido. Você poderá usar um único SET SCOPE pra tudo, dependendo de como vc for criar o índice.

Maickon Sato

[Jairo Maia]

Olá Ricardo,

Faço a procura usando Locate, tanto pelo Numero da Os como para localizar por tecnico e data

Mesmo você tendo indices, o Locate não os usam. O Locate faz uma varredura nos registros ignorando os índices. Veja aqui como ele funciona: Funcionamento do Comando LOCATE

Você precisa substitui-lo pelo DbSeek(), veja aqui: Usando DbSeek()

[billy1943]

Oi, Ricardo,

Como o Jairo aconselhou, o melhor é você usar o DBSeek(), ou seek.
Eu uso sem problemas a função ou comando, com o set softseek, sabendo-se que o seek para no registro que coincidir com a chave fornecida,
ou no seguinte, desde que não tenho chegado ao fim do arquivo, da seguinte forma:

Código: Selecionar todos

**********************************************************************************************************************
select arqpro
set order to ind1    // índice feito com os mesmos campos da chave abaixo
set softseek on
chave := codigo_prod + codigo_os + dtoc(data_os)  
seek chave
set softseek off

do while ! eof()  .and. (codigo_prod + codigo_os + dtoc(data_os) == chave)

    // localização imediata
    // tratamento no registro acessado....
    // até return

enddo

// se o fluxo seguir aqui, o registro não foi acessado, por EOF() ou por não coincidir chave de procura
// colocar mensagens informativas, etc.
************************************************************************************************************************

[Ricardo Sales Ribeiro]

Amigo Billy

Vou fazer essa implementação, agora pergunto.

Para um usuário corrente, acredito que funcione perfeitamente, para como será a performance, o sistema utilizando
essa rotina ao mesmo tempo para 6 usuários?

Vai ter a mesma rapidez?

Atenciosamente

[billy1943]

Quando um arquivo é aberto com seus índices em uma estação, o acesso é feito nesta, sem problemas, não importando quantos estações estão acessando esse
arquivo com seus índices.

Quanto às alterações que o mesmo sofre, você tem de controlar para que ninguém "prenda" o arquivo enquanto o estiver alterando, sendo essas alterações feitas
nas variáveis que ele abre quando da leitura do mesmo, e tão logo elas sejam modificadas o registro correspondente será bloqueado e rapidamente modificado.

Esse controle de semáforos é a parte mais complicada com quem trabalha em redes, porque você corre o risco de:
- alterar um registro que no momento está sendo modificado em outra estação: - qual versão ficará valendo ? a que alterar por último !
- você puxa um registro que está sendo alterado em outra estação: - seu conteúdo atual é o correto ? não, a não ser que não se faça nada na outra estação.

Como se desprende dessas poucas situações, processamento em rede não é questão somente de rapidez, mas também de segurança e trato das operações de
inclusão e alteração de registros por várias estações simultaneamente, pois não basta ir dando lock de arquivos, lock de registros e ir alterando tudo.

E olhe que nem citei as exclusões.

As estruturas de arquivos que sofrem muitas transações, como é o caso do sistema do Ricardo, devem ter um campo numérico, vamos chamar de assinatura, que no início da rotina de leitura é regravado no registro, após sofrer um acréscimo de 1 unidade, e também é guardado numa variável de memória.
Quando se termina as alterações desse registro, antes de regravar o mesmo, compara-se o valor da variável com o valor atual da assinatura constante do registro.
Se estiver diferente, significa que alguém alterou o registro nesse intervalo e suas alterações serão perdidas ou vão interferir no que outro operador efetuou.

Parece complicado, mas é dessa forma que mantem-se a integridade de sistemas onde várias estações estão a todo momento inserindo registros, alterando-os,
excluindo.

Em tempo: dada a rapidez que transações ocorrem é de bom princípio que você ponha um "timeout" em telas de edição dos dados, temporizando alguns segundos
(exemplo 30 segundos) para que as alterações sejam feitas, sob pena da rotina retornar ao menu anterior, pois existem operadores que abrem uma tela e vão
fazer outras coisas, segurando arquivos abertos, mesmo que os registros não estão bloqueados.

[Ricardo Sales Ribeiro]

Bom Dia
Amigo Billy

Entendi perfeitamente os procedimentos para tratamento de registros ou arquivos nas funções, de incluir,alterar, excluir e etc.
Vou implementar essa ideia que vc me passou no sistema.
Uma outra colocação, meu arquivo tem um campo chamado status, onde é gravado as seguintes informações:
P pendente, F finalizada, R revisita, C cancelada, no meu DbEdit estar aparecendo todas as situações, gostaria
de um comando para qdo carregar o DbEdit, só mostrar os registros cujo status seja P pendente ou R revisita, assim
meu arquivo mostrado no DbEDit vai ficar mais leve.

Atenciosamente

[billy1943]

Oi, Ricardo,

Novamente venho a sugerir:
- crie um índice para o campo Status
- coloque o arquivo em ordem para esse índice
- utilize a técnica do Dbseek ou seek, com set softseek ligado, para que o Dbedit apresente somente quando a chave contiver os caracteres "P" ou "R", nem que
seja primeiro pesquisando uma letra e depois a outra, pois o softseek é muito rápido, e se localizado a edição fica facilitada
- não use filtro, pois ele atrasa o processamento
- no Dbedit coloque o mínimo de campos possíveis

[billy1943]

Tem também algo para te possa ajudar neste tópico:

https://pctoledo.org/forum/viewto ... dit#p85379

[Ricardo Sales Ribeiro]

Bom Dia amigos

Caro Billy

Fiz os procedimentos de criação de indices, executei o DbEdit dentro da minha rotina, e deu certo, só mostra os registros
cujo status é P pendente ou C cancelada, beleza.

Nesta consulta implementei uma rotina de baixa, ou seja tecla F4 e a rotina pede para mudar o status de P pendente para
F finalizada, beleza funcionou, entretanto, como essa consulta não mostra os status tipo F finalizada, quando eu confirmo a atualização, o dbedit demora a me retornar, porque ele só mostra P e C, e ainda vai para o final do arquivo,
eu entendo, porque ele só mostra P e C.

Pergunta como fazer para resolver esse problema, contornar esse problema, eu uso essa rotina tipo consulta para mostrar
os registros pendentes e dar baixa, colocando finalizada, mas demora para retornar ao arquivo.

Por favor, uma dica para eu melhorar.

Atenciosamente

[billy1943]

Como você está trabalhando com um campo utilizado pelo índice (status), que tem no momento um valor P ou C, qualquer modificação nesse campo atualizará
o índice e mandará o ponteiro do arquivo para o final ou início (depende de sua rotina).
Até ele voltar no ponto de alteração (F4) vai demorar um pouco, dependendo do tráfego, do número de transações, etc.

Sugiro, infelizmente, criar mais um campo (não colocá-lo em índice algum), pois assim sua gravação não mexe em nenhum dos índices existentes.
Nesse campo, informe que o status está em F (finalizado), mas ainda não altere o campo.

Quando já tiver feito várias, mas várias alterações mesmo, pode até por um contador de transações, utilizando a F4, dê um refresh na rotina, passando
o conteúdo do novo campo (valor F) para o campo de status.
Pode até colocar na tela a informação de quais registros foram alterados, para seu controle e dos outros operadores também.
Aí então os índices serão regravados e o arquivo estará pronto para nova rodada de alterações, rapidinho.
Após isso, zere o campo suplementar para não atrapalhar e tornar mais rápida a nova rodada do refresh .
Do jeito que você está fazendo, alterando e trabalhando em cima de um campo indexado, você deixa os índices "loucos" e corre até o risco de corrompê-los.

É melhor fazer a mudança nos índices no atacado, do que fazê-los um a um, e esperar o sistema se recompor, não é ?

[Ricardo Sales Ribeiro]

Bom Dia!
Amigo Billy


Entendi, estou acompanhando aqui o desenrolar do sistema, voltei a trabalhar sem separar os status finalizados, melhorei as buscas com o seek, a demora é nas baixas, localizar e baixar.

Agradeço as dicas.

Atenciosamente

[Ricardo Sales Ribeiro]

Amigo Billy
Bom Dia

Gostaria de mais uma duvida, no mesmo sistema, agora na hora de gerar impressão:

Apos a digitação das Os´s de cada tecnico, o operador tem que imprimir uma comanda com os dados do tecnico a data
e as os´s desse dia que foram digitadas, em função do gande numero de registros estar demorando para gerar a impressão ok, fiz da seguinte maneira, de repente vc tem uma solução mais tecnica:

Entro com Codigo do Tecnico, e a data do dia,
Seleciono o Arquivo de Os´s, e gero um arquivo temporario com base nos dados digitados, Codigo Tecnico e Data, abro esse arquivo temporario e mando imprimir, como aão cinco operadores fazendo essa operação quase ao mesmo tempo,
e o arquivo muito grande, estar demorando, para gerar o arquivo temporario e imprimir.

Tem um indice no sistema, com o Codigo do Tecnico + Data

Por favor, me sugira uam saida melhor e mais rápida, o pessoal aqui estar me reclamando da demora, para gerar o arquivo temporario.

Código: Selecionar todos

   wCodEqu:=Space(03)
   wDatEnt:=Date()
   Set Colo To w+/bg
   @ 04,04 Say 'Codigo Equ.:'
   @ 06,04 Say 'Data       :'
   Set Colo To &C_CorGet
   @ 04,17 Get wCodEqu Pict '999'
   @ 06,17 Get wDatEnt Pict '99/99/9999'
   Read
   Clea Gets
   If LastKey() = 27
      DbCloseAll()
      Rest Scre From SgImpRot
      Return
   Endif
   Select a_CadEqu
   DbSeek(wCodEqu)
   If Eof()
      Som()
      Mensagem('Equipe NÆo Cadastrada...Tecle [ENTER]')
      Set Curs Off
      Inkey(0)
      Rest Scre From SgImpRot
      Return
   Endif
   wDesEqu:=DesEqu
   Select a_OrdSer
   Go Top
   wBak='ArqTem'+Substr(Time(),07,02)+'.Dbf'
   Copy To &wBak For (CodEqu = wCodEqu .and. DatEmi <= Date() .and. Status = 'P')
   Use &wBak Exclusive Alias a_Bak New
   Select a_Bak
   Go Top
   If Eof()
      Som()
      Mensagem('Arquivo Vazio... Tecle [ENTER]')
      Set Curs Off
      DbCloseAll()
      Erase('&wBak')
      Rest Scre From SgImpRot
      Return
   Endif

Atenciosamente