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.