Página 1 de 1
Usar COMMIT nos processamentos
Enviado: 22 Nov 2007 11:22
por clodoaldomonteiro
Olá!
Estava dando uma geral nos meus fontes de processamentos, onde pego dados de um DBF e repasso (REPL) em outro DBF e surgil uma dúvida.
Eu devo usar o COMMIT antes do USE, CLOSE ou CLOSE ALL ?
Enviado: 22 Nov 2007 11:29
por Maligno
Não adianta nda antes do USE e nem depois do CLOSE. O comando COMMAND tem por finalidade descarregar os buffers internos para o arquivo destino. Assim, as mudanças se tornarão imediatamente visíveis a outro usuário, em rede.
Ao executar um REPLACE, os dados não vão imediatamente para o arquivo. Usa-se COMMIT para forçar essa situação. Mas se o CLOSE vem em seguida, não há por quê usar COMMIT. Por outro lado, após um REPLACE pode vir outro ou vários outros. COMMIT, como trabalha com disco, é lento se executado seguidamente. O uso ideal é, após um REPLACE (ou vários), não seguido por CLOSE, executar apenas um COMMIT para descarregar os dados e continuar trabalhando no arquivo.
Enviado: 22 Nov 2007 11:42
por alaminojunior
O comando COMMAND....
Gente, o Maligno tá precisando de umas férias

) Brincadeirinha...
Só complementando...
sempre depois dos replaces antes de destravar o registro, use então DBCOMMIT() pois ele atua somente no banco atual, causando uma lentidão menor.
Enviado: 22 Nov 2007 11:55
por Maligno
Maligno escreveu:O comando COMMAND....
Cruzes!!!!
Só complementando...
sempre depois dos replaces antes de destravar o registro, use então DBCOMMIT() pois ele atua somente no banco atual, causando uma lentidão menor.
Complemento muito oportuno. Obrigado. Sempre esqueço desse detalhe: o comando COMMIT é traduzido para dbCommitAll() que, aliás, eu nunca uso.
Enviado: 23 Nov 2007 00:22
por clodoaldomonteiro
É, vi no asquivo STD.CH que o comando COMMIT chama o DBCOMMITALL() e tava vendo nos estudos de c++ que é mais produtivo usar as funções e não os comandos, acho que isso já foi comentado aqui também.
Nos processamentos que faço não vou precisar COMMIT e nem o DBCOMMIT() depois dos REPLACE, já que uso os arquivos em modo exclusivo, assim o sistema fica mais leve.
Enviado: 23 Nov 2007 02:49
por Maligno
clodoaldomonteiro escreveu:É, vi no asquivo STD.CH que o comando COMMIT chama o DBCOMMITALL()
Esse comando COMMIT, pra evitar confusão, deveria se chamar COMMITALL.
tava vendo nos estudos de c++ que é mais produtivo usar as funções e não os comandos, acho que isso já foi comentado aqui também.
Se foi comentado não lembro. Em C++ não existem comandos compostos como os do Clipper, mas comandos simples que não podem ser substituídos. Mas no quesito produtividade, não faz diferença o que se usa. Claro que isso dependende do codificador. Mas é muito mais fácil uma queda no nível de manutenibilidade do que no de produtividade.
Em Clipper é diferente. Na maior parte das vezes não dá pra trocar comandos por funções. Basta ver o conteúdo de um PPO pra entender por quê.
Nos processamentos que faço não vou precisar COMMIT e nem o DBCOMMIT() depois dos REPLACE, já que uso os arquivos em modo exclusivo, assim o sistema fica mais leve.
Não tem acesso multiusuário?
Enviado: 23 Nov 2007 09:19
por alaminojunior
Acredito que vai dar na mesma, mas a documentação da CA informa que:
um simples GOTO RECNO() descarrega o buffer atual em disco...
deve ser um dbcommit() escondido !?
Enviado: 23 Nov 2007 11:08
por Maligno
Não um dbCommit() escondido, mas um efeito coloteral de mover o ponteiro para o mesmo lugar. Tá com cara de bug que deu certo.

))
Enviado: 23 Nov 2007 17:21
por clodoaldomonteiro
Maligno escreveu:Não tem acesso multiusuário?
Tem sim, só que quando faço processamentos, pego vários arquivos para analizar e gerar registros em um arquivo diário, eu os abro em modo exclusivo.
Se não quando eu tiver totalizando uma conta, e outro usuário incluir um lançamento, os saldos das contas vão ficar furados.
É um fechamento mensal.
Enviado: 23 Nov 2007 17:32
por Maligno
Se o sujeito fizer um lançamento após o processamento, os saldos das contas ficarão furados do mesmo jeito. Quando for imprimir o balanço ele já estará furado.

Enviado: 23 Nov 2007 17:46
por Pablo César
Era isso mesmo que ia dizer. De quê adianta brecar todo mundo se o resultado final será o mesmo. O que poderia ser considerado, nesses relatórios (ou até consultas) é colocar a data e hora para não houver discrepâncias nos relatórios sub-seguintes.
Ja se sabe que tão somente poucos casos é aconselhado o uso do READONLY, numa rede mais ainda.
Enviado: 24 Nov 2007 00:20
por clodoaldomonteiro
Pessoal!
É que a rotina é de fechamento do mês e o usuário sabe que tem que usá-la para para atualizar as tabelas.
Quando ele altera uma tabela, eu altero uma variável para .f., e quanto ele usa o fechameno do mês essa variável passa a ser .t., assim quando ele for imprimir os relatório tem como eu saber se falta fechar o mês ou não.
Não sei se tem uma maneira melhor de fazer isso.
Ps. O sistema é basicamente de contabilidade, só que contabilidade pública, bem mais complicado.