PC Toledo

Quintas,

A variável nTentativas no seu ponto de vista ficará contando infinitamente ? ao meu ver tem que ter uma saída, eu pensei em abortar a aplicação depois de 20 tentativas

aSimoes,

Ficou show sua função. Muito boa.

Com relação a Numero de Tentativas, eu tbm sou da mesma opinião do Quintas: limitar isso eh uma péssima idéia.

Imagina que numa rotina vc vai gravar em tabelas:

Tabela1 passou ok

Tabela2 passou ok

Tabela3 o DbAppend falhou

Se depois de x tentativas vc abortar a gravação na tabela3, a consistência do seu banco de dados vai pro beleléu. E aí? vai desfazer as gravações JA REALIZADAS nas tabelas 1 e 2?

É como o Quintas falou, até da pra controlar isso, mas haja toneladas de códigos para cada rotina.

Janio

PS: Mais um dia sem erro no cliente hehehe. Ou resolveu, ou a rotina que me manda email de erro pifou kkkk

Bom,

Ha duas saídas para o problema acima:

1-) Se a rotina de gravação é em apenas uma tabela, pode-se após X tentativas perguntar ao cidadão que ta na frente do computador se ele deseja abortar a operação;

2-) Se a rotina de gravação é EM VÁRIAS tabelas, fica difícil perguntar ao usuário pra abortar em alguma tabela, quando ja foram gravados dados em outras. No entanto, se vc usar algum BANCO DE DADOS RELACIONAL e usar TRANSAÇÕES... em falhando a gravação em alguma tabela, depois de x tentativas vc pode perguntar se deseja abortar. Se a resposta for SIM vc manda um ROLLBACK que o banco se encarrega de DESFAZER o que tinha sido feito pra cima

Janio,

Como diria o ditado "se está bom assim porque mudar" só uma observação do que você disse:

Tabela1 passou ok

Tabela2 passou ok

Tabela3 o DbAppend falhou

O que acontece na Tabela3 depois de 1000000 de tentativas, abort ou retry ?, ou o usuário vai se cansar da mensagem, sabe como é usuário né, acha que a máquina travou e taca o dedão no botão reset ou liga/desliga, estou sendo bem pessimista, mas se tratando de rede se uma coisa pode dar erro, vai dar erro, e quais as consequências? kkkk

E outra se o erro é em uma tabela filha ? vai ter registro órfão ?

Outra situação:

Tabela filha é um sequencial de número de pedido, gravou a ordem 1, 2 a 3 falhou e a aplicação espera o 3 ou pula o 3 ?, são tantas emoções que deixa o programador careca, é por isso que não tenho mais cabelo.

Até mesmo a opção de "não infinito" não uso mais.
Mas dá pra usar, por exemplo na alteração/exclusão. Mas em qual situação o usuário esperaria infinitamente?

Se estiver tudo ok, vai ok.
Se estiver com problema... erro é erro, melhor nem ter o trabalho de tentar controlar.... rs

Imagine a rotina já apresentada...
Começou a fazer dá erro... começou a desfazer dá erro.... deu no mesmo.... rs

Por isso acabei removendo a opção de intervalo de tempo.
Acabei acrescentando o skip 0, porque pode ser que depois de bloquear precisa atualizar o buffer com algo alterado por outra estação.
Se estava bloqueado... pode ser que aquilo foi excluído.

De qualquer forma, vai da lógica do conjunto, e não apenas da rotina em si.
Pode ser que sirva pra um padrão de fontes, mas não pra outro.
Se existisse um padrão considerado certo, não precisaria programador, porque seria sempre igual e estaria pronto.

Quintas

Mas em qual situação o usuário esperaria infinitamente?

Só o Janio para responder essa, enfim foi ele que criou o monstro, kkkkk

kkkkkkkkkkkkkkk

Erro é erro, nenao Quintas kkkkk

Ok, vamos dizer que esperar eternamente não seja o correto rsrsrs. Mas dar opcao pro usuario abortar depois de 20 mínguas tentativas tbm não da ne.

O que me incomodava nesse erro, e isso foi inédito pra mim, foi qndo ele dava no caixa problematico, alardeava em todos os outros em cadeia. O supermercado do cliente PAROU num dia pra vcs terem uma idéia, e um supermercado parado (nem que seja por 5 minutos), vcs nao sabem a dor de cabeça que eh kk (cliente ligou pra mim umas 100x em 5 minutos kkkk)

Ainda continua falhando o DbAppend nesse caixa? Possivelmente sim. Possivelmente ele fique la tentando em milhares de vez. MAS PELO MENOS ESSE PROBLEMA NÃO ESTA MAIS 'ATRAPALHANDO' OS OUTROS CAIXAS e o super do homi não para mais rsrsrs

Janio,

Só uma coisa, o cliente desse supermercado com 2 carrinhos cheios até a boca no meio da transação passando o produto no leitor e de repente o famigerado dbappend falha, isso já aconteceu comigo em um supermercado aqui do rio de janeiro, o que você faz ? espera ? larga tudo e vai embora ? ou começa quebrar tudo baseado no filme "Um dia de Fúria" kkkkk

kkkkkkkkkkkkkk

Se falhar no caixa problemático vai tentar, tentar, tentar... até o usuário ficar p*to kkkk

Se as outras estações falharem por causa da problemática... tenta uma vez, duas, três e acredito que antes das 10 da certo e ele continua rsrs.

O meu erro era pq eu tentava UMA VEZ e pronto. Deu certo, deu. Não deu, lascou-se.

Qndo dava erro e a gravação ficava pela metade, eu tinha ERRO de SEQUENCIA do CCF das impressoras fiscais. Somente no dia 10 desse mes (dia do famigerado aperreio), está faltando 3 cupons fiscais. Ou seja, os cupons foram emitidos, estão registrados na impressora fiscal, mas para o sistema eles NAO EXISTEM.

Depois da atualização com essas funções, pergunta aí se ainda houve quebra nesse sequencial: NÃO HOUVE!

Acho q ta funcionando rsrsrsrs

Janio

PS: O cliente emite em média 52.000 cupons fiscais mensais. Eh um numero considerável

Janio,

Eu pensaria em uma solução de dbf temporário por caixa e no final, transportar tudo para base real, é só uma sugestão, sem concorrência de uso no mesmo dbf, menos problemas de lock, não é infalível mas ficaria mais performático.

O caixa tem sangria que eu saiba, nesse momento poderia transportar tudo para a base real e zerar o dbf temporário, sei lá to viajando, eu só não quero ir nesse supermercado dai, vou quebrar tudo e ainda vou chamar o programador pra pagar a conta, kkkkk

asimoes escreveu:Janio,

Eu pensaria em uma solução de dbf temporário por caixa e no final, transportar tudo para base real, é só uma sugestão, sem concorrência de uso no mesmo dbf, menos problemas de lock, não é infalível mas ficaria mais performático.

O caixa tem sangria que eu saiba, nesse momento poderia transportar tudo para a base real e zerar o dbf temporário, sei lá to viajando, eu só não quero ir nesse supermercado dai, vou quebrar tudo e ainda vou chamar o programador pra pagar a conta, kkkkk

Yo sé muy poco sobre la administración de base de datos, por lo tanto lo que voy a decir es pura especulación teórica, la idea Alexandre es interesante, si el problema es de concurrencia y se debe tener una DB centralizada en tiempo real por ej. para consulta del gerente, es tentadora la idea de usar una DB central y una local por máquina. Se almacenan la info en las 2 DB a la vez, luego cada cierto intervalo de tiempo se compara si todos los registros de la local están en la central, si falta alguno se copia a la central, luego se borra la local o se deja como un backup de esa máquina. Otra opción es gravar en la local sólo si falla el registro en la central y después se crea un thread aparte que se va encargar de copiar los reg de la local a la central y a medida que va copiando con éxito un registro lo va deletando de la local. Como ya dije esto es pura especulación teórica.

Essa ideia de temporários pode ser útil, e na máquina local onde está o temporário pode até ser mapeada para rede, dessa forma a aplicação que gerencia todo o sistema pode ter acesso a esse temporário das estações.
Fazendo o papel de carga das estações para o sistema principal no servidor ou vice-versa, pode ser também até uma aplicação monitor que faça a carga a cada x tempo.

Imaginando o cenário:

Estações com a pasta \CAIXA estação com seu dbf correspondente:

cx001.dbf cx002.dbf cd003.dbf

No servidor uma aplicação systray para ler o dbf de cada caixa a cada x minutos, condensando os registros na base real.

É só uma ideia, tem que ver se compensa o esforço.

Só tive paz depois q fiz tudo em temporário e no final grava nas tabelas reais... se cair a energia ou algo do tipo ao entrar verifica q tem o temporário e recupera.

Também só resolvi meu problema com uma tabela temporaria de itens... Deu BO e a maquina foi reiniciada ou travou o sistema por algum motivo qdo entra de novo pelo menos os itens que já foram lançados estão lá armazenados...
Agora o preocupante mesmo é as rotinas "fortemente acopladas". Sinceramente não sei o que fazer... Eu tenho por hábito enviar a NFCe primeiro e se não conseguir enviar, não tiver cstat=100 faz o que manda em contigencia e continua o processamento ou não termina a venda. (eu mando em contigencia e faço os outros procedimentos), daí tem gravar a venda, baixa no estoque, lançamento no caixa/contas a receber/cheque, voltar apagar o orcamentos, apagar os itens do orçamentos e por aí vai..
Meus problemas foram praticamente resolvidos com a troca de ntx por cdx. Não vi nas postagens qual o Leandro tá usando.
Outra coisa só para mencionar, tive um problema enorme com um alias "ORC" não sei porque... tinha uma rotina que ao fechar o caixa fechava todos os dbfs com dbcommitall() e dbcloseall() e abria o arquivo de orcamentos "ORC" em modo exclusivo e dava um pack. Bom a ideia era essa, só que por algum motivo o tal do "ORC" não abria nem com reza, sempre dava erro de que o Alias já existia.
Recentemente um cliente meu de outra cidade me reclamava que fazia venda, gravava e imprimia, mas não registrava no caixa... Fiz de tudo para resolver isso mas não consegui reproduzir o erro em nenhum outro cliente. Por algum motivo trocaram de funcionária e a nova funcionária me ligou pedindo para dar uma olhada na máquina por que achava que tava com vírus, porque do nada o sistema congelava e só funcionava quando resetava. Pronto resolvido o problema dos dados não gravados no caixa.. em algum momento o Servidor dela congelava e justamente na rotina de gravação... se me lembro foi comentado tambem que as duas máquinas que rodavam o programa abriam e faziam lançamentos no caixa... tudo foi encaixando né... Máquina com hd com defeito que congelava. E caixa travado pelo outro terminal. Bom cada caso é um caso...

Rubens