Talvez trocar o comando COMMIT ( que grava em todas as areas abertas) pela função DBCOMMIT(), que executa a gravação somente na area ativa.
Se for o caso de uma gravação de vários registros em lote, mesmo que em mais de uma área, essa troca, mesmo que faça efeito, não resolve totalmente, já que, em prol da segurança, ele ainda terá que emitir um commit em cada área envolvida. Seria como um cobertor curto: cobre uma parte e descobre outra. Mas ainda acho que a raiz do problema está em outro lugar.
[]'s
Maligno
--- Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
--- Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Enfim ... tive problemas com lentidão na gravação de registros... a troca do comando pela função foi bem útil, pois ao ganho com a velocidade foi surpreendente.
Depende de como a questão abertura de arquivos é tratada.
Se forem abertos todos de uma vez no começo do sistema, até onde meu conhecimento (que não é muito grande) alcança, o COMMIT rodaria em todos os bancos de dados, sem necessidade... ou não?
Então só nos resta esperar nosso colega responder se o problema foi solucionado...
anacatacombs escreveu:Se forem abertos todos de uma vez no começo do sistema, até onde meu conhecimento (que não é muito grande) alcança, o COMMIT rodaria em todos os bancos de dados, sem necessidade... ou não?
Nesse caso especial de abertura de todos os bancos, o COMMIT global realmente tem de vasculhar todas as áreas pra saber onde disparar um flush dos dados. Aí sim, claro, haverá uma perda de tempo, maior quanto mais tabelas estiverem abertas. Fica um pouco pior se em algum ponto o programador esquece de emitir um COMMIT. Daí é feito tudo de uma vez. Manter abertas todas as tabelas, a meu ver, é uma prática horrível. Aliás, também nesse ponto a arquitetura cliente/servidor é muito melhor. Você usa só o que precisa usar e o servidor cuida da "burocracia".
[]'s
Maligno
--- Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
--- Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
ja passei por um problema, que acho parecido, inclusive postei aki, mas nao tive resultado positivo.
da uma olhada, se for o mesmo caso...rs
caso consiga a solução, agradeço
Edegar
Por experiência própria inclusive na internet, para compartilhar micro através do (arq shared) é lento mesmo, por isso qualquer tentativa de resolver isso fica dificil, aconselho por um hub.
...a troca do comando pela função foi bem útil, pois ao ganho com a velocidade foi surpreendente.... o COMMIT rodaria em todos os bancos de dados...
Anacatacombs,
Vc não disse qual função era, então vou arriscar um esclarecimento: se vc trocar o comando COMMIT pela função DBCOMMITALL(), o resultado vai ser o mesmo. Ambos, comando e função, 'FLUSHeiam' todos (ALL) os arquivos abertos em todas as áreas.
Já a função DBCOMMIT() cuida só da área em foco, aí pode ficar "mais rápido" mesmo.
No entanto, precisa analisar a visibilidade que vc precisa nas alterações: se vc usar a DBCOMMIT() e tiver alterado coisas em várias áreas de trabalho, as áreas não alcançadas pelo "flush" podem não mostrar imediatamente as atualizações para as demais estações na rede, e isso pode ser um problema.
Por experiência própria inclusive na internet, para compartilhar micro através do (arq shared) é lento mesmo, por isso qualquer tentativa de resolver isso fica dificil, aconselho por um hub.
WCardoso,
Confesso que não entendi. O que tem a ver um HUB com o SHAREamento de arquivos?
Por experiência própria inclusive na internet, para compartilhar micro através do (arq shared) é lento mesmo, por isso qualquer tentativa de resolver isso fica dificil, aconselho por um hub.
Sinceridosamente.......tem certeza que postou a resposta no lugar certo ?
Se sim, pergunto: Os micros estavam interligados por qual meio então ?
Compilador xHarbour 1.2.3 + Embarcadero C++ 7.30
MySQL c/ SQLRDD
HwGui + GTWVG
Devemos considerar também, ja que não vimos o codigo que possa causar este problema, que filtragens e relacionamentos pode fazer esta lentidão aumentar a cada maquina que acesse o modulo em si.
aebrturas simultaneas não causam lentidão, mas filtragens e relacionamentos sim. SET FILTERs e SET RELATIONs podem causar isto.
Se sua tela de cadastros for baseada em BROWSE/DBEDIT esta lentidão pode acontecer. Geralmente em modulos que usam este tipo de programação pode abrir a tabela principal e vincular tabelas filho para outras apresentações ou visualizações, pois enquanto o browse estiver ativo, cada rolagem de registros pode perfazer os filtros de vinculos.
Ex: um browse sobre a tabela de clientes e que tenha como filtros filhos os pedidos do cliente vinculado. Se o meio de filtragem for SET FILTER ou SET RELATION, varias aberturas pderão causar esta lentidão.
Sugestão: Usar escopos.
Se a inclusão ou alteração é acionada diretamente via opção em menu que abre uma tela/ficha para digitação, provavelmente o gargalo poderá estar na abertura dos arquivos e filtragens posteriores.
A sugestão para uso de escopos envolve o uso de RDD apropriado com CDX ou SIX, portanto, se for para melhorar, mude.
Verificar o hardware também pode ajudar, ainda mais se identificar se as velocidades estão compativeis, exemplo, placas de rede de mesma velocidade que o hub/concentrador.
Desabilitar o uso de acesso a internet ou diminuir a banda relacionada a mesma para que toda banda seja somente de uso da rede. O Windows defineum percentual desta banda para uso próprio e de serviços de verificação desnecessários.
Atualizações automáticas do Windows tendem a ficar baixando da internet incontáveis patches entupindo sua banda com downloads de hora impróprias.
Quanto ao uso de DBCommit() eu também uso em cada área e geralmente precedido de dbRUnlock() ja que o dbAppend/APPEND FROM ou dbRlock()/RLOCK foi usado para travar o registro é muito bom destravá-lo antes de COMMITá-lo.
Uso Windows Server enterprise 2003, tunado, em uma rede com mais dois micros, trabalhando com 100% de downloads ativos, Terminal services abertos e Teamviewer ativos, fazendo testes em meu aplicativo com bases de dados abertas de muitos registros e sempre que noto algum gargalo verifico meu codigo para otimiza-lo, partindo em ultimo caso para a tunagem da maquina.
E por ultimo, memória, eu uso o parametro de velocidade da maquina para colocar memória na maquina. Se as maquinas possuem até de 500Mhz, 500Mb de memória deixa elas um avião. Se possuem 1Ghz coloco 1Gb e assim por diante. Por sorte os pentes estão caindo de preço.
Se o caso não for memória, sugiro baixar da net uma versão de Windows mexida que leve para a memória somente serviços uteis para rede como é o caso da TinyXP e XP Gamer Edition. Versões preparadas para subir em maquinas com até 64mb de memória, colocando nas mesmas apenas 16 serviços ativos.
Para tornar estas versões mexidas e versões despirateadas, após a instalação troque o serial pelo serial de seu Windows XP original, pois a licença original suprime o uso do XP pirata.
OPS! LINK QUEBRADO? Veja ESTE TOPICO antes e caso não encontre ENVIE seu email com link do tópico para [url=mailto://fivolution@hotmail.com]fivolution@hotmail.com[/url]. Agradecido.
@braços : ? )
A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
Varios programadores abominam o uso do set filter e o set relation entao nem se fala, tudo tem que ser feito manualmente, mas um dos recursos mais legais do clipper e justamente as tabelas ou seja o dbedit e o browse que da para fazer coisas muito praticas mesmo, quase pirei quando descobri que dava pra fazer algo assim no clipper 10 anos atras, sem muita dificuldade de programacao.
Ja tentei no passado utilizar o dbedit sem usar o set relation, mas tudo que fiz nao teve sucesso, exceto se fosse a replicacao de dados desnecessarios aumentando consideravelmente o tamanho do banco de dados,o que era crucial ja que o hd era de 120mb na epoca =)), e o processador um 286 bons tempos aqueles kkk.
Pablo César.
Você sabe, em espanhol, o equivalente de "Agendador de tarefas" - ("Task Scheduler" em inglês) – Vou testar essa opção e ver si a lentidão se elimina.
Pablo César, es mi deseo y mi oración que el año 2009 sea para vos un año de grandes realizaciones y que Dios te prospere, a vos y a toda tu familia.
Também estão inclusos na minha oração todos os que participam deste foro.
Adalberto escreveu:Você sabe, em espanhol, o equivalente de "Agendador de tarefas" - ("Task Scheduler" em inglês)
Ahhh sim Adalberto em espanhol é "Agendador de Tareas" e você refere-se ao que eu disse neste tópico ? Pois bem experimente e nos retorne para nos contar se essa opção é plausível ou não.
Muchas gracias Adalberto por tus preciosos deseos hacia mi, mi familia y a todos los participantes de aqui del fórum. Aprovecho tambien para desearte lo mismo a ti colega y a todo el pueblo hermano boliviano, principalmente todos aquellos que aqui participan así como vos, aportando a la programacion y dando un brillo especial de internacionalizacion de nuestro querido Clipper.
GOD BLESS YOU !
Um clip-abraço !
Pablo César Arrascaeta Compartilhe suas dúvidas e soluções com todos os colegas aqui do fórum.
Evite enviar as dúvidas técnicas por MPs ou eMails, assim todos iremos beneficiar-nos.
