Clipper On Line • Ver Tópico - Custo X benefício na manipulação de dbf/cdx
Página 1 de 2

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 06 Ago 2013 20:19
por lugab
Então, pessoal, eu sempre quis ler a opinião de vcs sobre qual das 2 linhas de trabalho abaixo deve-se adotar, usando Harbour-janela e Dbf/dx

O objetivo, sempre, é obter mais segurança contra erros nos índice e maior rapidez de execução possível.

Em suma, qual o custo x benefício de ...

1) deixar abertos todos os Dbf/cdx necessários no início do programa e só fechá-los ao final do programa

2) Abir e fechar os Dbf/cdx várias vezes dentro do programa, a cada consulta , ou a cada gravação ou a cada exclusão...

Gabriel

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 07 Ago 2013 17:17
por Duda 'Sgluber'
Gabriel,

já que você pede opiniões, vou deixar a minha! :-)

Desde quando comecei a escrever sistemas que acessavam bases de dados, decidi que faria a abertura/fechamento várias vezes durante a execução dos programas. Ou seja: na minha opinião, é temerário abrir as bases de dados/índices uma única vez e fechar somente no encerramento do sistema. E desde lá atrás, ainda nos tempos de programação em DOS, quando fiz um bocado de testes com vários DBFs/NTXs para comparar a velocidade de abertura/fechamento várias vezes durante a execução, cheguei à conclusão de que valia a pena adotar esse conceito.

É verdade que os sistemas operacionais utilizados atualmente oferecem mais segurança e a perda de dados (genericamente falando) é menor do que antigamente e, portanto, minha posição poderia ser revista, mas até agora não vejo motivos para mudar: ao longo dos anos tive muito poucos problemas com perda/corrupção de dados.

Então, é como diz o ditado: "não se mexe em time que está ganhando!" :-)

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 07 Ago 2013 23:54
por lugab
Duda,

Dar vários open/close num DBF/CDX na mesma aplicação não torna o bicho lento ?

E se esse Dbf possuir um número elevado de registro e com várias chaves/cdx ?

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 08 Ago 2013 08:39
por pauloa1
Com certeza abrir e fechar dbf e cdx somente quando precisa.
Vamos supor que seu sistema tenha 50 tabelas, é pouco provável que o usuário vai usar todas elas , todos os dias.

Caso der um problema no pc, rede etc.. tem chance de detonar apenas os arquivos que estavam aberto, sem falar que em rede quanto mais arquivos abertos em pcs diferentes, mais lento fica.

Paulo

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 08 Ago 2013 16:42
por Duda 'Sgluber'
Gabriel,

é claro que abrir e fechar as tabelas/índices váras vezes exige mais tempo do que manter tudo sempre aberto; também é claro que quanto maior o número de registros nos DBFs, quanto maiores e mais complexos forem os índices associador a eles, maior será o processamento.

Mas aí voltamos ao mais importante deste assunto, bem descrito por você mesmo ao criar este tópico: custo x benefício. Para mim, os benefícios de abrir e fechar os arquivos várias vezes durante a execução do sistema (de acordo com a demanda, evidente), são muito maiores do que o custo de uma ligeira perda de tempo.

Aproveitando o assunto, outra coisa que faço há tempos e que recomendo é a abertura dos DBFs como somente leitura sempre que possível. Ou seja: se você está abrindo tabelas e índices para gerar um relatório, para que precisa abri-los com acesso total?

Tem aquele outro ditado: "Cautela e caldo de galinha nunca fizeram mal a ninguém!" Imagem

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 08 Ago 2013 17:04
por sambomb
Abre o mínimo possível a menor quantidade de vezes possíveis, seu objetivo é só ter o DBF aberto quando for manipular ele mas sem abrir e fechar várias vezes.

Em geral, a cada opção você inicia abrindo os DBF's necessários antes da abertura ( com uma barra de progresso se necessário ) e fecha após fechar a tela.

Evite Set Relation e Set Filter ao máximo, ambos podem ser substituídos por um índice bem estruturado e matriz.

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 08 Ago 2013 20:29
por sygecom
Eu também sempre abri usei e fechei os DBF e ÍNDICE, penso comigo se ficar muito tempo aberto e der o azar de uma queda de luz, pode corromper, estragar e etc...ai já viu a meleca que da.

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 10 Ago 2013 03:30
por lugab
Ok, por unanimidade de opiniões, o mais vantajoso é abrir, manipular e fechar, em vez de abrir no ínicio do program e fechar só ao seu final..

Muitíssimo obrigado a todos.

Agora, pessoal, como é que se faz abertura dos DBFs somente para leitura , como propôs o Dudu ?

Confesso que só conheço os comandos "USE ARQUIVO SHARED" e "USE ARQUIVO EXCLUSIVE"

gabriel

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 10 Ago 2013 04:26
por Duda 'Sgluber'
lugab escreveu:...
Agora, pessoal, como é que se faz abertura dos DBFs somente para leitura , como propôs o Dudu ?
...
gabriel


Hehehe... Eduardo raramente é chamado pelo nome: é Duda, Dudu, Edu, Du... eu cresci ouvindo me chamarem de Duda, mas aceito as demais formas, Gabriel! Imagem

Quanto a abrir em somente leitura... conheceu o glorioso Norton Guides, utilizado para navegar pelo Guide to CA-Clipper? Esse era dos tempos do DOS, depois apareceu o Expert Guide for Windows e há não muito tempo encontrei o http://www.ousob.com/norton.php. Dê uma olhada e veja que delícia! Imagem

Localize "The Guide To Clipper 5.3" e siga em frente. Acredito que a melhor forma de detalhar o comando USE é lendo diretamente o manual, que atualmente pode ser facilmente acessado a partir deste endereço. O link direto para o comando USE é http://www.ousob.com/ng/53guide/ngf8dbc.php (acabei de acessar).

Abs! Imagem

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 10 Ago 2013 17:39
por lugab
Uau.... valeu Duda !!!!


USE [<xcDatabase>
        [INDEX <xcIndex list>]
        [ALIAS <xcAlias>] [EXCLUSIVE | SHARED]
        [NEW] [READONLY]
        [VIA <cDriver>]]


Poder abrir com "readonly" é dez....

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 12 Ago 2013 11:26
por VanderSimples
Poder abrir com "readonly" é dez....


Eu entrei recentemente nesse forum com uma dúvida sobre este assunto.

Em meus teste descobri que em Rede se o DBF estiver aberto em outro terminal, a troca de registros (skip) dentro do mesmo é extremamente prejudicado.

Em meus sistema somente deixo os DBFs abertos nas telas que estão utilizando o mesmo. Por exemplo: quando entra ne tela de cliente Abro o arquivo de clientes ao sair eu fecho o arquivo, mas se nesse meio tempo em outro terminal alguém for fazer um relatório que corre a tabela cliente fica bem mais lento.

Realmente não conhecia esta dica do ReadOnly, vou testar.

Quem desejar ler o tópico com os testes que realizei: http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=14345
Obs.: este é apenas um exemplo, numa situação real a quantidade de registo é bem maior, mas se com 1000 registros ja da uma diferença dessas imaginem com mais.

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 19 Ago 2013 04:18
por lugab
Amigos, testei a cláusula READONLY e não entendi a sua finalidade.

Abri um arquivo ( USE ARQTESTE SHARED READONLY ALIAS TESTE ) , simulei quedas de energias e o arquivo CDX foi corrompido.

Em função disso, qual seria vantagem de ter que alterar algumas dezenas de fontes de impressão de relatórios, para inserir a cláusula Readonly ?

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 20 Ago 2013 16:53
por Duda 'Sgluber'
Gabriel,

e o DBF, foi corrompido? Aposto que não, estou certo? Imagem

A ideia é essa: se o DBF está preservado, você pode recriar os índices. Mas se o DBF estiver corrompido...

Vale lembrar que a cláusula READONLY está presente no comando USE, e não no INDEX ON, por motivos óbvios: se você está criando um índice, evidentemente ele será gravado em disco. Foi assim que você simulou a queda de energia? Se positivo, aí não tem jeito mesmo, né? Imagem

Mas há um detalhe interessante: se você tiver o índice criado e atualizado antes de usá-lo, as chances de corrupção diminuem.

Eu faço assim: quando vou usar tabelas que não necessitam acesso total e podem ser abertas com READONLY, simplesmente abro os índices previamente criados, não volto a criá-los. Em outras palavras: nesses casos eu uso SET INDEX, não INDEX ON.

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 20 Ago 2013 17:43
por lugab
Entendi, Duda,

Acredito que 99.99% dos problemas de corrupção é com os índices, mesmo.

Eu tento evitar isso, dessa forma:

- sempre que dou um SEEK eu pergunto se o item achado é o mesmo da chave

Mas isso só funciona quando obtenho uma resposta .NOT. EOF()

E vcs, o q seus programas fazem para descobrir um indice corrompido e evitar que usuários continuem incluindo, alterando e excluindo dados num DBF/CDX ?

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 22 Ago 2013 19:42
por rochinha
Amiguinhos,

E vcs, o q seus programas fazem para descobrir um indice corrompido e evitar que usuários continuem incluindo, alterando e excluindo dados num DBF/CDX ?


Reindexar. Não tem outro jeito. Não existe meios de recuperar um índice corrompido, tendo em vista que o mesmo é descartável.

Para teste de integridade da tabela .DBF voce pode usar a função contida em Função para teste de integridade de .DBF( Uso Geral )

Caso deseje trabalhar com vetor e simular SQL gerando um arquivo temporário sem muito trabalho, veja o tópico Super seleção de dados com ordenação dos registros.

Usar readonly não vai resolver o problema de corrupção dos dados vistos que o mesmo só acontece devido a realocação de memória ocorrida no cache do S.O. enquanto os aplicativos estão abertos.

Uma melhoria no cache geralmente se consegue quando modificamos o método de controle fazendo com que o cache não demore para liberar seu conteúdo quando um aplicativo abandonou seu uso pelo fechamento das tabelas, algo com fechamento atrasado.

A corrupção das tabelas geralmente ocorrem porque enquanto se usa a tabela, o cache esta sendo manuseado por aplicativos que fazem muita escrita no cache e o vilão é o Internet Explorer e o que ocorre é que muito lixo proveniente de páginas é salvo junto ou no meio dos dados, reescrevendo a tabela e sumindo com registros.

Deseja para de ter problemas?

Use um servidor de dados dedicado, onde o mesmo somente tenha os dados acessados e que não seja usada para nada.
Use NetIO ou LetoDB, com eles o servidor executará o módulo server, receberá comandos e retornará o resultado para seus aplicativos em rede de forma mais tranquila.

Se o seu aplicativo ficar em um servidor, qualquer besteira que seus usuários façam no terminal não trará danos diretos ao seus dados.

Custo X benefício na manipulação de dbf/cdx

MensagemEnviado: 24 Ago 2013 00:15
por lugab
Rochinha, obrigado pelo teste no DBF.

Para detectar se um CDx está corrompido, sempre q dou um seek em um DBF/CDx e acho o registro, testo a chave passada com os campos do reg.encontrado, e isso tem me ajudado, mas é muito pouco...

Me faltam idéias para realizar o mesmo TESTE DE INTEGRIDADE quando o SEEK cai no EOF() , ou seja, qdo não acha o registro pesquisado...

Não sei como checar qdo o regist
ro existe , mas não foi achoado pq o CDX está corrompido...