OLHA QUE ESTRANHO. NEM DA PRA EXPLICAR NO TITULO..
Olha que coisa estranha.
Fiz um programa em Vb para o financeiro. O programinha funciona legal. Faz toda a rotina do financeiro (pagar, receber, consultar, etc.). O banco de dados é ACCESS 2000, usando DAO.
Eu compilei o projeto, fiz o programa de instalação, instalei nos usuários e tudo beleza.
Enquanto os usuários do financeiro estavam lá usando o programa felizes da vida, eu resolvi fazer uma alteração no formulário de consulta.
Aàeu abri o projeto no VB, fiz uma alteração qualquer e rodei pra testar. Mas aàtodas as estações que estão com o programa instalado, ficam leeeeeeeeeeeeeeeeeentas... Lentas demais!!
Tipo, uma pesquisa que levava 1 segundo, leva quase 10 segundos!!!
Não é estranho!?!?
Aàé só eu fechar o projeto (com o código fonte) e pedir para os usuários fechares o programinha e abrirem de novo, que tudo volta ao normal.
Não é estranho mesmo!?!
Pra resumir. O projeto é o mesmo. Só que para os usuários é o projeto compilado (o executável instalado nas estações) e pra mim é o projeto com o código fonte, que rodo a partir do VB.
O que teria a ver executar o projeto no VB (sem compilar) com o projeto compilado???
São bancos de dados diferentes. O que os usuários estão usando é o que dados reais (fin.mdb) e o outro, que eu uso pra testes, é uma cópia do original (finTeste.mdb)
Os bancos de dados estão no mesmo compartilhamento no servidor. (Z:\dados\)
De resto, uso DAO com DataGrid, ADODC programado via código. Mas até aànão acho que isso tenha a ver.
O servidor não executa nenhuma tarefa que possa ser responsável por essa lentidão. O processador fica em 98% e o consumo de memória é mÃÂÂnimo. Tanto no servido quanto nas estações.
O problema só acontece quando eu abro o código fonte no VB e executo pelo VB. Aàas estações ficam lentas. E só voltam ao normal quando eu fecho o projeto e os usuários abrem e fecham de novo o programa.
Alguém já viu algo assim?
Fiz um programa em Vb para o financeiro. O programinha funciona legal. Faz toda a rotina do financeiro (pagar, receber, consultar, etc.). O banco de dados é ACCESS 2000, usando DAO.
Eu compilei o projeto, fiz o programa de instalação, instalei nos usuários e tudo beleza.
Enquanto os usuários do financeiro estavam lá usando o programa felizes da vida, eu resolvi fazer uma alteração no formulário de consulta.
Aàeu abri o projeto no VB, fiz uma alteração qualquer e rodei pra testar. Mas aàtodas as estações que estão com o programa instalado, ficam leeeeeeeeeeeeeeeeeentas... Lentas demais!!
Tipo, uma pesquisa que levava 1 segundo, leva quase 10 segundos!!!
Não é estranho!?!?
Aàé só eu fechar o projeto (com o código fonte) e pedir para os usuários fechares o programinha e abrirem de novo, que tudo volta ao normal.
Não é estranho mesmo!?!
Pra resumir. O projeto é o mesmo. Só que para os usuários é o projeto compilado (o executável instalado nas estações) e pra mim é o projeto com o código fonte, que rodo a partir do VB.
O que teria a ver executar o projeto no VB (sem compilar) com o projeto compilado???
São bancos de dados diferentes. O que os usuários estão usando é o que dados reais (fin.mdb) e o outro, que eu uso pra testes, é uma cópia do original (finTeste.mdb)
Os bancos de dados estão no mesmo compartilhamento no servidor. (Z:\dados\)
De resto, uso DAO com DataGrid, ADODC programado via código. Mas até aànão acho que isso tenha a ver.
O servidor não executa nenhuma tarefa que possa ser responsável por essa lentidão. O processador fica em 98% e o consumo de memória é mÃÂÂnimo. Tanto no servido quanto nas estações.
O problema só acontece quando eu abro o código fonte no VB e executo pelo VB. Aàas estações ficam lentas. E só voltam ao normal quando eu fecho o projeto e os usuários abrem e fecham de novo o programa.
Alguém já viu algo assim?
Só uma observação. é o programa que eu fiz que fica lento nas estações, não o Windows e o resto dos programas.
Ola...
Ja pensouna possibilidade de virus?
Sua rede pode estar infectada.
Abraços.
Ja pensouna possibilidade de virus?
Sua rede pode estar infectada.
Abraços.
Nao é virus nao JB....
Se nao me engano pode ser o proprio sistema de Prioridades do Windows... Ele pode entender como uma prioridade alta o seu VB com o codigo fonte aberto e deixar OS COMPILADOS com menos prioridades.... Ou ate msm prioridades do banco de dados access...
T+ ESPERO TER AJUDADO...
Se nao me engano pode ser o proprio sistema de Prioridades do Windows... Ele pode entender como uma prioridade alta o seu VB com o codigo fonte aberto e deixar OS COMPILADOS com menos prioridades.... Ou ate msm prioridades do banco de dados access...
T+ ESPERO TER AJUDADO...
Bom, vÃÂÂrus não é...
Em relação às prioridades, pode até ser. Mas como isso pode acontecer se o código fonte está na minha máquina e o programa compilado está na outra?
Como o banco de dados original e o de testes estão no mesmo compartilhamento, vou tentar colocar o de testes em outro compartilhamento. Pois é a única coisa que pode ligar os fatos... Pelo menos até agora.
Vou tentar depois posto aqui.
Em relação às prioridades, pode até ser. Mas como isso pode acontecer se o código fonte está na minha máquina e o programa compilado está na outra?
Como o banco de dados original e o de testes estão no mesmo compartilhamento, vou tentar colocar o de testes em outro compartilhamento. Pois é a única coisa que pode ligar os fatos... Pelo menos até agora.
Vou tentar depois posto aqui.
- Se é vÃÂÂrus, com toda a certeza o nome dele é "DAO".
- Você abriu um dos formulários pelo projeto, para fazer uma alteraçãozonha apenas. Mas o projeto contém:
- Formulários com controles do tipo DataControl?
- ActiveX Design do tipo DataEnvironment?
- ActiveX Design do tipo DataReport/CrystalReport vinculado?
- Cada formulário que você "desenha" na aplicação, carrega todo o banco de dados, quer você queira ou não, pois o DAO trabalha desse modo. Ao usar um DataControl mapeado (onde se indica o banco pelo painel de propriedades e não por código), o banco é carregado mesmo em tempo de desenho, sem se executar nada. Pela IDE do VB, agora "rodando" o projeto, se o mesmo formulário for "testado" três vezes, quebrando-se a execução na metade (CTRL + BREAK), a instância anterior do banco NÃO é eliminada, ou seja, a rede vai ficar com TRÃÅ S instâncias do banco de dados "pendurada", e o próprio banco idem. Desse modo, basta um só formulário em modo de desenho (com vários DataControl) ou cuja execução pela IDE do VB tenha sido "quebrada" para que, não só a comunicação toda se torne muito mais lenta, como também para que o risco de danos á base de dados seja exponencialmente aumentado. Para DESENVOLVIMENTO, use SEMPRE um banco de dados DIFERENTE do banco de dados de trabalho, e de preferência, NÃO use DataControl, ADODCs, DataEnvironments etc, mas apenas código. Mesmo com essas precauções, a rede ainda pode ser sobrecarregada por aquilo que você faz em sua estação, portanto, cuidados extras nesses quesitos são muito importantes sempre.
4 - Rede. A sua estação pode possuir privilégios (direitos) maiores, o que garante á ela um "status" de prioridade nas requisições. Se fÃÂ'r assim, quaisquer problemas na sua estação serão refletidos nas demais estações, ao menos nas que possuem status inferior. Um efeito "cascata" pode surgir apenas de um Runtime Error que você esteja intencionalmente testando.
5 - Todos os formulários de seu projeto DE FATO fecham os Recordsets que abrem ANTES de serem encerrados, e a instância DATABASE também é convenientemente fechada ao encerrar o aplicativo? Se não, mesmo nos executáveis (ou seja, os compilados), você precisa tomar esse cuidado com a urgência maior que puder. Além disso, um Runtime Error mal tratado pode acarretar uma conexão com o banco que ficará "pendurada" na rede, consumindo mais e mais recursos. em uma rede onde vários usuários podem "sofrer" erros de execução que "quebram" a aplicação, isso pode resultar em desde uma perda de eficiência até situações muito mais graves.
6 - Seção compartilhada / seção isolada. A maioria dos bancos de dados, incluindo o MS-Access, permitem que se trabalhe com seções distintas, o que também "alivia" a carga das operações, além de isolar de modo mais eficiente os processos. No caso do Access, é necessário um arquivo de sistema (MDA) e a criação de usuários e direitos de acesso para essa opção chegar á um nÃÂÂvel razoável. Você está trabalhando desta forma? é conveniente adotar esse recurso? Se sim, a administração dos direitos não está conflitante de algum modo?
Desse modo, o problema (que aliás é velho conhecido) pode ter uma ou mais causas, pode se agravar e até colocar em risco as informações existente, como pode ter sido pontual e "desaparecer".
é interessante repassar o aplicativo para ver se não há algum dos "desvios" de codificação citados, assim como sobstituir tanto controles mais "pesados" por outros mais "leves" e passar á utilizar instruções SQL que realizem estritamente o necessário, evitando trafegar um volume de informações maior do que se vá efetivamente processar.
Uma dica que em minha opinião é a mais "quente" para a sua situação, é você substituir a DAO pela ADO, que, apesar de ter uma carga inicial mais demorada, é muito mais eficiente, no sentido de que não carrega todo o banco de dados nem requer uma conexão aberta o tempo todo.
- Você abriu um dos formulários pelo projeto, para fazer uma alteraçãozonha apenas. Mas o projeto contém:
- Formulários com controles do tipo DataControl?
- ActiveX Design do tipo DataEnvironment?
- ActiveX Design do tipo DataReport/CrystalReport vinculado?
- Cada formulário que você "desenha" na aplicação, carrega todo o banco de dados, quer você queira ou não, pois o DAO trabalha desse modo. Ao usar um DataControl mapeado (onde se indica o banco pelo painel de propriedades e não por código), o banco é carregado mesmo em tempo de desenho, sem se executar nada. Pela IDE do VB, agora "rodando" o projeto, se o mesmo formulário for "testado" três vezes, quebrando-se a execução na metade (CTRL + BREAK), a instância anterior do banco NÃO é eliminada, ou seja, a rede vai ficar com TRÃÅ S instâncias do banco de dados "pendurada", e o próprio banco idem. Desse modo, basta um só formulário em modo de desenho (com vários DataControl) ou cuja execução pela IDE do VB tenha sido "quebrada" para que, não só a comunicação toda se torne muito mais lenta, como também para que o risco de danos á base de dados seja exponencialmente aumentado. Para DESENVOLVIMENTO, use SEMPRE um banco de dados DIFERENTE do banco de dados de trabalho, e de preferência, NÃO use DataControl, ADODCs, DataEnvironments etc, mas apenas código. Mesmo com essas precauções, a rede ainda pode ser sobrecarregada por aquilo que você faz em sua estação, portanto, cuidados extras nesses quesitos são muito importantes sempre.
4 - Rede. A sua estação pode possuir privilégios (direitos) maiores, o que garante á ela um "status" de prioridade nas requisições. Se fÃÂ'r assim, quaisquer problemas na sua estação serão refletidos nas demais estações, ao menos nas que possuem status inferior. Um efeito "cascata" pode surgir apenas de um Runtime Error que você esteja intencionalmente testando.
5 - Todos os formulários de seu projeto DE FATO fecham os Recordsets que abrem ANTES de serem encerrados, e a instância DATABASE também é convenientemente fechada ao encerrar o aplicativo? Se não, mesmo nos executáveis (ou seja, os compilados), você precisa tomar esse cuidado com a urgência maior que puder. Além disso, um Runtime Error mal tratado pode acarretar uma conexão com o banco que ficará "pendurada" na rede, consumindo mais e mais recursos. em uma rede onde vários usuários podem "sofrer" erros de execução que "quebram" a aplicação, isso pode resultar em desde uma perda de eficiência até situações muito mais graves.
6 - Seção compartilhada / seção isolada. A maioria dos bancos de dados, incluindo o MS-Access, permitem que se trabalhe com seções distintas, o que também "alivia" a carga das operações, além de isolar de modo mais eficiente os processos. No caso do Access, é necessário um arquivo de sistema (MDA) e a criação de usuários e direitos de acesso para essa opção chegar á um nÃÂÂvel razoável. Você está trabalhando desta forma? é conveniente adotar esse recurso? Se sim, a administração dos direitos não está conflitante de algum modo?
Desse modo, o problema (que aliás é velho conhecido) pode ter uma ou mais causas, pode se agravar e até colocar em risco as informações existente, como pode ter sido pontual e "desaparecer".
é interessante repassar o aplicativo para ver se não há algum dos "desvios" de codificação citados, assim como sobstituir tanto controles mais "pesados" por outros mais "leves" e passar á utilizar instruções SQL que realizem estritamente o necessário, evitando trafegar um volume de informações maior do que se vá efetivamente processar.
Uma dica que em minha opinião é a mais "quente" para a sua situação, é você substituir a DAO pela ADO, que, apesar de ter uma carga inicial mais demorada, é muito mais eficiente, no sentido de que não carrega todo o banco de dados nem requer uma conexão aberta o tempo todo.
na maquina existe o mdb que é acessado por outras máquinas certo, e é esse mesmo que vc está acessando tambem em modo design do bv certo.
crie um banco de dados vazio e vincule todas as tabelas, e acesse este banco de dados em modo design do vb. dessa forma não irá mudar a performance de outras máquinas.
este procedimento não é só acessando em modo design do vb não, se o banco de dados do servidor for acessado do prório servidor causa uma lentidão nas outras máquinas de rede. Isso porque o access da prioridade a máquina local.
exemplo
servidor
BandoDados.mdb
se este banco for acessado do próprio servidor, tem que se criar
BancoDado1.mdb e vincular as tabelas do BancoDados.mdb
crie um banco de dados vazio e vincule todas as tabelas, e acesse este banco de dados em modo design do vb. dessa forma não irá mudar a performance de outras máquinas.
este procedimento não é só acessando em modo design do vb não, se o banco de dados do servidor for acessado do prório servidor causa uma lentidão nas outras máquinas de rede. Isso porque o access da prioridade a máquina local.
exemplo
servidor
BandoDados.mdb
se este banco for acessado do próprio servidor, tem que se criar
BancoDado1.mdb e vincular as tabelas do BancoDados.mdb
Pois é Professor,
Dei uma checada no código fonte e não havia nenhhum recordset aberto e somente um processo referente ao executável está rodando.
O mais estranho é que foi de uma hora pra outra. Abri o código-fonte, alterei o formato de exibição de uma coluna, salvei, gerei o executável só. Porém foi depois disso que o problema apareceu.
Já no banco de dados, alterei o formato de um campo de NUMERO para TEXTO.
Será talvez que isso tem alguma coisa a ver com o problema?
Como você falou, estou usando sim um controle ADODC, com DataGrid. Porém, as instruções SQL são via código. O controle somente é usado para conectar o DataGrid ao .MDB através do ADODC. Fora isso, uso SQL.
E + uma coisa tb... O projeto tá demorando mto pra finalizar quando eu termino de rodar testes em tempo de projeto (Start - F5).
Pelo que você falou, creio que tem muito a ver com o DAO e alguns controles, porém, por que só agora? Por que de uma hora pra outra?
Continuando a fazer testes...
Dei uma checada no código fonte e não havia nenhhum recordset aberto e somente um processo referente ao executável está rodando.
O mais estranho é que foi de uma hora pra outra. Abri o código-fonte, alterei o formato de exibição de uma coluna, salvei, gerei o executável só. Porém foi depois disso que o problema apareceu.
Já no banco de dados, alterei o formato de um campo de NUMERO para TEXTO.
Será talvez que isso tem alguma coisa a ver com o problema?
Como você falou, estou usando sim um controle ADODC, com DataGrid. Porém, as instruções SQL são via código. O controle somente é usado para conectar o DataGrid ao .MDB através do ADODC. Fora isso, uso SQL.
E + uma coisa tb... O projeto tá demorando mto pra finalizar quando eu termino de rodar testes em tempo de projeto (Start - F5).
Pelo que você falou, creio que tem muito a ver com o DAO e alguns controles, porém, por que só agora? Por que de uma hora pra outra?
Continuando a fazer testes...
Meus camaradas... Acho que fiz merda...
Fiz uns loops pra executarem dentro do programa. Esses loops fazem soma de campos de valores.
Exemplo:
Esse loop soma todos os valores pagos durante o ano.
O problema é que eu mandei o programa executar esse loop toda vez que alguém paga alguma coisa. Ou seja, recalcula o ano todo por causa de um único pagamento feito. E como são pagos várias coisas durante o dia.... já viu....
Executei um debug (aquele que a gente marca uma linha e vai apertando F8 pra ver a execução linha a linha). E pro meu espanto...... To quase 7 minutos com o F8 pressionado e não acabaram os loops do programa!! :(
Que mancada...
Por outro lado... Não estava assim até o dia em que eu fiz a alteração no código fonte... Mesmo com mais de 5000 registros pro coitado do programa verificar, ele ainda tava rapidinho. Só foi eu fazer a alteração no código fonte (que não tem nada a ver com loops) e o danado ficou leeeeeeeento....
Bom, dexa eu continuar com o F8 pressionado pra ver quanto tempo mais vai demorar... Aàvou desfazer essa caca que fiz.... Os loops....
Fiz uns loops pra executarem dentro do programa. Esses loops fazem soma de campos de valores.
Exemplo:
Set rs = db.OpenRecordset("SELECT Valor " & _
"FROM tblPagar " & _
"WHERE Ano = " & " " & varIDAnoPagar & " " & _
"AND Pago = 'OK'")
Do Until rs.EOF
ValorAnoPago = ValorAnoPago + rs!valor
rs.MoveNext
Loop
rs.Close
set rs = nothing
Esse loop soma todos os valores pagos durante o ano.
O problema é que eu mandei o programa executar esse loop toda vez que alguém paga alguma coisa. Ou seja, recalcula o ano todo por causa de um único pagamento feito. E como são pagos várias coisas durante o dia.... já viu....
Executei um debug (aquele que a gente marca uma linha e vai apertando F8 pra ver a execução linha a linha). E pro meu espanto...... To quase 7 minutos com o F8 pressionado e não acabaram os loops do programa!! :(
Que mancada...
Por outro lado... Não estava assim até o dia em que eu fiz a alteração no código fonte... Mesmo com mais de 5000 registros pro coitado do programa verificar, ele ainda tava rapidinho. Só foi eu fazer a alteração no código fonte (que não tem nada a ver com loops) e o danado ficou leeeeeeeento....
Bom, dexa eu continuar com o F8 pressionado pra ver quanto tempo mais vai demorar... Aàvou desfazer essa caca que fiz.... Os loops....
Tenta Isso...
Set rs = db.OpenRecordset("SELECT SUM(Valor) as Valor" & _
"FROM tblPagar " & _
"WHERE Ano = " & " " & varIDAnoPagar & " " & _
"AND Pago = 'OK'")
ValorAnoPago = rs!Valor
Set rs = db.OpenRecordset("SELECT SUM(Valor) as Valor" & _
"FROM tblPagar " & _
"WHERE Ano = " & " " & varIDAnoPagar & " " & _
"AND Pago = 'OK'")
ValorAnoPago = rs!Valor
Pois é ANTONIOBSJ,
Isso que vc postou é o que deve ser feito.
O correto é guardar numa variável o valor total, na inicialização do programa. E quando algo for pago, terá que fazer o valor pago + valor atual da variável.
O problema está sendo sanado. Ttenho que alterar mta coisa no código fonte... :(
Mas a dúvida fica no ar... por que essa lentidão foi acontecer somente depois que eu fiz uma alteração minúscula (no formato de um campo do DataGrid), que aparentemente não tem nada a ver.
Antes da alteração levava pouco mais de 1 segundo pra fazer a atualização, executar todos os loops, etc. Depois passou a demorar mais de 12 segundos...
Isso que vc postou é o que deve ser feito.
O correto é guardar numa variável o valor total, na inicialização do programa. E quando algo for pago, terá que fazer o valor pago + valor atual da variável.
O problema está sendo sanado. Ttenho que alterar mta coisa no código fonte... :(
Mas a dúvida fica no ar... por que essa lentidão foi acontecer somente depois que eu fiz uma alteração minúscula (no formato de um campo do DataGrid), que aparentemente não tem nada a ver.
Antes da alteração levava pouco mais de 1 segundo pra fazer a atualização, executar todos os loops, etc. Depois passou a demorar mais de 12 segundos...
Tópico encerrado , respostas não são mais permitidas