Abrir ou não todos os arquivos no início

[Poka]

Olá a todos

Quando comecei a programar. abria todos os arquivos no inicio do sistema.depois passei a abrir somente na rotina chamada, por exemplo, em contas a receber, a pagar, etc.

Hoje estou voltando a abrir todos no inicio novamente, por ser + fácil.

Já se falou muito sobre isso aqui, mas gostaria de perguntar o seguinte:

Tenho um sistema de empresa em que praticamente todos estao utilizando o sistema o dia todo, contas a receber, a pagar, bancos, almoxarifado, custos etc ., consequentemente todos os arquivos estarão abertos. Uma parada de energia nesse momento não seria o mesmo se tivesse aberto totos os arquivos no inicio?

Gostaria de uma opinião dos colegas.

Até mais,

[gransoft]

ARAGUARI-MG, 6 de fevereiro de 2005.

Prezado Poka,

A questão de se abrir TODOS os arquivos de dados e índices ao mesmo tempo, esbarrava na limitação do MS-DOS e GPF/Windows 9x, o tal "FILES=255".

Um Aplicativo que abra 60 arquivos compartilhados, ao ser inicializado pelo quinto "terminal", da Rede Local, tornaria instável e imprevisível o gerenciamento no "Servidor", acarretando perda de dados, duplicações de registros e corrupção de índices. Exatamente o que ocorre quando da falta de energia...

Nos verdadeiros "Servidores de Arquivos", LANtastic antigamente, Novell, GNU/Linux SaMBa e GPF/Windows mais parrudos, a limitação de quantidade de arquivos é bem maior do que a real necessidade da maioria dos usuários.

Eu adoto a técnica de "abrir-usar-fechar", e em algumas situações, também a técnica do "Semáforo", que restinge a abertura de arquivos dependendo do que o outro usuário esteja fazendo.

No GPF/Windows 9x, o utilitário NetWatch.exe ajuda a monitorar os arquivos abertos no Servidor.

Atenciosamente,
Janis Peters Grants.

Skype: gransoft
http://www.gransoft.com.br
gransoft@zipmail.com.br

[Mário Isa]

Eu abro todos no início.
Por causa da queda da energia sempre dava pau nos arquivos.
Agora eu faço o seguinte. A cada 30 minutos os arquivos são fechados e reabertos e a cada venda ou recebimento ou rotinas que atualizam diversos arquivos, no final destas os arquivos são fechados e reabertos.
E aí não mais paus.... Graças a Deus.

Abraços
Mário

[vagucs]

Fechar e abrir os arquivos faz o mesmo que o DBCOMMITALL, em meu maior cliente eu também tinha muitos problemas com corrupção de arquivos, ai mudei o sistema para trabalhar sempre com os bancos fechados, abrindo sempre que necessário.

Tenho duas rotinas que podem dar uma idéia, se alguém precisa é só entrar em contato que passo elas.

A desvantagem de abrir os arquivos toda hora é que há uma perda de velocidade, pois quando eles ficam sempre abertos as informações ficam em cache, quando fecha elas são apagadas do cache e depois relidas... somente isto, mas isso só no primeiro acesso ao arquivo, mas no geral você ganha demais em segurança.

[Mário Isa]

sou obrigado a discordar plenamente do colega Wagner.
Eu usei dbcommittall() durante muitíssimo tempo mas nada resolveu.
A energia acabava e quando ela voltava meu celular começava a tocar sem parar.

fiz uma rotina que pegava todos os .dbf e dava um pack e depois um recall all em todos funcionava mais ou menos.

Agora, depois de adotar o procedimento acima meus problemas acabaram. E olha que não foi tabajara que resolveu hein tsc tsc tsc
Abraços
Mário

[Jorge Adourian]

Esta mania de achar que fechar os arquivos dá segurança é pura PARANÓIA.

Eu uso a abertura no início há 18 anos desde o Clipper Winter´85 e tive rarríssimos casos de DBF corrompido, e sempre que ocorreram foram provocados por outros motivos, memória RAM defeituosa, ou placa de rede defeituosa.

Portanto, aos mais novos, indico usarem a abertura no início sem medo, e não fiquem jogando a culpa de uma corrupção eventual de DBF no fato dele estar aberto por muito tempo. Até porque o problema pode ocorrer exatamente quando você abrir o DBF.

Para quem não sabe, um arquivo DBF aberto (principalmente no modo SHARED), não é como uma planilha EXCEL que se não for gravada de tempos em tempos se perde. No DBF, um simples SKIP ou GOTO grava o BUFFER em disco (além do COMMIT óbviamente), e a partir daí fechar ou não o DBF não faz a menor diferença. Lembro ainda que em modo SHARED o BUFFER do DBF é de apenas um registro por SELECT.

Portanto, acredito que quem fecha os arquivos a toda hora por medo, esta se deixando levar pela desinformação e não em uma Base Técnica.

O único motivo pelo qual se deve fechar e abrir a cada modulo os DBF é a limitação de FILES, que hoje em dia com o uso de RDD DBFCDX ou SIXxxx, ficou bem mesnos problemático, uma vez que vários arquivos de índices podem ser embutidos em um único arquivo CDX ou NSX.

[Dudu_XBase]

Boa Tarde Vou dar minha opinião.
Eu abro somente os arquivos qdo vou utilizá-los depois fecho novamente.
Vamos lá qdo vc solicita dados de um registro de um dbf na rede, vc recebe uma cópia do msm que fica armazenado nos seus buffers locais, portando suas alterações estarão sendo feitas sobre essa cópia, a função COMMIT tem a função de transferir os buffers locais para os buffers do servidor, mas existem problemas em alguns micros a função COMMIT é ignorada pelo sistema operacional não sei pq..fiz uns testes simulando quedas de energia..., mantendo os arquivos no buffer da memória, e qdo caiu "um raio" no cliente....esses buffers perdidos que ficaram na memória geram o famoso erro que todos nós conhecemos o CORRUPTION DETECTED.
Qdo vc fecha o arquivo e abre novamente caso existir algum buffer na memória ele é atualizado, como função DBCOMMITALL() deveria fazer, por isso o colega Wagner a citou pela semelhança no propósito. Qdo vc , fecha os arquivos e os abre novamente eu uso dessa forma na maioria dos casos, é certeza que os buffers sejam fisicamente atualizados no servidor.
Qto a performance vc perde realmente tem casos que abro mais de 100 dfbs numa tacada só não esquecendo os indíces logicamente que eu usava o NTX. Imagine tinha um senhor dbf com seus mais de 150 megas e 15 indices ele era o rei dos CORRUPTION DETECTED, tb mais de 50 usuários usando o bixim, qdo vc usa o NTX o sistema aloca um handler para cada indice aberto e mais uma para o arquivo dbf somando os demais dbfs, a abertura era uma lentidão só até coloquei uma mensagem e uma barrinha de progresso mostrando pro caboclo qto faltava para carregar...rs.
Solução migrei tudo para usar indices compostos estou usando o NSX, mas tb tem o CDX tb é uma blz.
Pq ? Para abrir hj meus arquivos mais famigerados aloco somente 2 handlers um para o arquivo dbf outro para o indice composto, no meu caso eu estou usando o indice NSX.
Com a migração para esse novo rdd ganhei mta performance velocidade , estabilidade e espaço pois o indice composto além de ser gerado mais rapidamente, seu tamanho é bem menor, por exemplo nesse meu senhor dbf o tamanhos dos "ntxs" somando todos passavam de 100 megas, o indice composto gerado tem menos de 30 megas, sem contar que o limite de 15 indices abertos para o msm banco no padrão NTX já era, porque eu no NSX eu posso criar até 50 tags (indices) e no CDX até mais que 50 e ficarão agrupados tudo num unico arquivo por isso chama-se indice composto, e qdo vou criar um indice novo só incremento ele na rotina de reorganização, pq tb se agrupará no indice, eu somente adicionarei a nova rotina colocando um dbsetorder() novo, diminuindo assim cada vez q tinha q criar um indice novo adicionar ele no set index, há anos que não me deparo com o 1012 CORRUPTION DETECTED.
Eu tb abro alguns arquivos como usando a claúsula READONLY qdo o não será executado atualizações no mesmo faço dessa forma nas consultas pois ele não aloca os buffers locais para escrita (write) do arquivo e até abre mais rapidamente.
E concordo com o Jorge que citou que problemas tb são gerados por questão de hardware. Placa de Rede, memória RAM, cabeamento com interferência elétrica, hub zuado esses dias tivemos que trocar e lascar um switch....esses problemas acabam nos transtornando pois o cliente com certeza ligará para vc num domingo pela manhã...caramba nem na feira eu posso ir em paz....rs... e não para o técnico de hardware.
Se eu estiver errado favor me corrijam pois serei sempre um aprendiz.

[Jorge Adourian]

Insisto em lembrar que em modo SHARED um simples SKIP ou GOTO ou qualquer movimento no registro atual equivale a um DBCOMMIT(), pois o Clipper só guarda 1 registro no BUFFER, e se movemos o ponteiro ele não tem outra saída a não ser gravar o BUFFER para poder carregar o novo registro, e isto não tem como discutir.

[Dudu_XBase]

(y) isso é com certeza Jorge damos mta enfase ao comando COMMIT nas outras respostas.
Já vi que não é só eu q não esta na Praia nesse momento...ainda bem q o estoque de (b)...aki do freezer "ainda" esta cheio...mas depois que resolver a bucha do cliente...vou prum churras... e vou levá-las no isopor comigo....aff...

[vagucs]

É isso ai galera, me esprecei mal, mesmo usando o DBCOMMITALL eu ainda tive problemas de corrupção, pois neste cliente meu tem muitas máquina, quase sempre quando dava uma queda de energia acontecia a corrupção do arquivo porque sempre tinha algum registro sendo alterado que ainda não recebeu o commit, em momento de horário de almoço as corrupções não aconteciam, e como jorge citou, já tive problemas de corrupção por causa de cabos de rede corroidos, memória e até joguinhos na hora que o patrão saia.

Quanto a SKIP fazer um COMMIT ele faz sim, mas local, as mudanças não ficam visíveis nos outros terminais, pois o Windows tende a fazer um buffer além do que o Clipper já gera para o aplicativo e o DBCOMMIT faz com que o sistema operacional grave esta mudança fisicamente, pois se usarmos apenas SKIP ou algo assim o sistema fica louco, o estoque não anda etc... de qualquer forma o DBCOMMIT é indispensável e o fechamento de arquivo faz o mesmo.

Confessamos outra coisa também, o Windows 95 ou 98 ou ME como servidor não dá para encarar... eles são os reis da corrupção de arquivo, muito mal no terminal. No servidor o Windows XP ou Samba sanaram de vez problemas de corrupção.

[Jorge Adourian]

Quanto a SKIP fazer um COMMIT ele faz sim, mas local, as mudanças não ficam visíveis nos outros terminais, pois o Windows tende a fazer um buffer além do que o Clipper já gera para o aplicativo e o DBCOMMIT faz com que o sistema operacional grave esta mudança fisicamente, pois se usarmos apenas SKIP ou algo assim o sistema fica louco, o estoque não anda etc... de qualquer forma o DBCOMMIT é indispensável e o fechamento de arquivo faz o mesmo.

Vagner me desculpe, mas você está invertendo as coisas, pois é exatamente o comportamento em Rede é que faz o SKIP equivaler a um COMMIT e em modo local é que não.

O Windows não atrasa a gravação...Faça o teste e verá !!!

Assim que o COMMIT (ou seu equivalente) é executado o dado já esta diponível para todos os outros usuários da Rede !!!

Se você não quer testar...Leia o trecho no Manual do Clipper:

In a network environment, any record movement command, including SKIP,
makes changes to the current work area visible to other applications if
the current file is shared and the changes were made during an RLOCK().
To force an update to become visible without changing the current record
position, use SKIP 0. If, however, the changes were made during an
FLOCK(), visibility is not guaranteed until the lock is released, a
COMMIT is performed, or the file is closed. Refer to the Network
Programming chapter in the Programming and Utilities guide for more
information.

[Domenico]

Pois é pessoal, se tem um assunto polêmico é este.

Vou apenas dizer como sempre trabalhei:

Salvo execessões, abro todos os arquivos no início e fecho ao encerrar o sistema.

Se já tive problemas com corrupção?

Sim, mas quem não teve, backup é para resolver estes inconvenientes.

Certa vez ouvi de um experiênte analista a seguinte frase:

Se pode dar problema, tenha certeza que em algum momento dará. Trabalhe para minimizar os problemas. Lembre-se sempre que o sistema está contra você, ele é seu grande inimigo.

Parece coisa de filósofo, mas esta é a realidade.

[vagucs]

Jorge,

Sem contextamento, a muitos anos atrás eu comecei a programar em redes e fiz os testes para verificar se quando incluia algum dado ele estaria disponível na rede e realmente só ficava disponível após o commit, mas não conhecia essa propriedade do Skip.

É assim, vivendo e aprendendo.

Mas vale que quando coloquei meu sistema para abrir e fechar os arquivos a cada operação a corrupção de indices caiu para "0".

Abraços.

[Daniel]

eu tambem abro os dbf so na hora que eu for usar, no começo eu abria tudo era corrupçao, arquivos duplicados e outro mais agora zero tudo. tenho um programa que usa todos eles abertos so que roda e linux com xharbour ai e beleza pura.

[Tim9]

Antigamente quando tinha restrições a memória eu abria e fechava os arquivos na medida do uso. Já naquela época tive problema de corrupção e fui a fundo e observei que o SKIP grava fisicamene, posteriormente vi a necessidade e a importância do DBCOMMIT assim como do RLOCK e UNLOCK.

Atualmente com o advento do LINKADOR BLINKER que acho muito bom, tenho uma função para abrir todos os arquivos no início do programa e outra p/ reindexar todos quando for preciso. Mas tudo com RLOCK e DBCOMMIT bonitinho como manda o figurino. E nunca mais tive problemas, não sei se estou isento mas tomo todas as precauções possíveis.

Concluindo abrir tudo no início é bem mais prático.

Fui!