EMBarbosa

E mais uma agora: Essas estatísticas que mandou por último, sobre os índices e tabelas, foi depois de um backup/restore?

Opa desculpa a vergonha que eu passei. kkkkkkkkkk Parecia que eu tinha lido esse tópico em outra área...

Acredito que esse "parâmetro" que fala é o Sweep Interval. O Sweep Interval vem habilitado pois é normal em 90% dos BDs. O último link que eu passei explica boa parte dos conceitos e funcionamento do garbage collector. Em via de regra, só se deve desabilitar o Sweep Interval quando há um número muito grande de transações (mais de 20 mil) ocorrendo num período curto (algumas horas ou minutos). Em geral basta configurá-lo para um número maior... E claro, se você o desabilita, então terá que manualmente fazer garbage collection. Enfim... Não lembro de ter lido sobre o seu caso, então não vou entrar em mérito se o que lhe informaram estava certo ou não... Mas pelo que o sesistemas passou até agora, ainda não vi motivos para o Sweep Interval dele estar zero. Pode ser que depois dele me responder as várias coisas que perguntei eu mude de ideia.

Essas estatísticas aí são só o cabeçalho (gstat -h). Eu queria o restante para que eu pudesse relacionar ao insert que você faz. Acredito que você deva saber que esteja você utilizanado um ClientDataSet ou não, não faz tanta diferença. Por traz provavelmente é executado um SQL do mesmo jeito. As vezes mais ou menos eficiente. Eu lembro deste post que você citou aí. A Ann H. é quem sempre tirou minhas dúvidas sobre as partes internas do FB. Você analisou o gstat -a -r como ela diz pra fazer? Chegou a conclusão que realmente são as versões anteriores dos registros que estavam atrapalhando os índices? Com respeito ao número de transações, não estou vendo nada anormal até o momento. O limite para o número de transações é +/- 231-1. Assim, quando você chegar perto de 2147483648 então você precisa ficar preocupado. Por exemplo, quanto tempo esse BD aí estava sendo executado após o Backup/restore? O que eu notei é que o Sweep Interval está desabilitado. Isso significa que o garbage collection não vai executar automaticamente. Você o executa manualmente? Quando? Esse artigo aqui explica um pouco mais sobre o assunto, que é importantíssimo para administradores de BD Firebird.

Não esqueça de começar descrevendo o que você quer fazer. Eu não tenho acesso à lista de discussão que você citou.

Acho que você pode estar confundindo alguma coisa ou não dando informações completas. O ACBrNFe não é dependente da LCL. Ele também funciona no Delphi. Ele não depende do Fortes, pois pode-se utilizar outros gerenciadores de relatório para imprimir como o RAVE. Seria possível você descrever melhor o problema que está encontrando? Mensagens de erro, o que já tentou, o que esperava que acontecesse e o resultado que na verdade obteve são informações que também podem ajudar...

O que é esse M na frente?

Já tem tópico falando sobre MG aqui no fórum. Procure por portaria SRE 132.

Realmente, o ACBrMonitor Plus ainda está em fase Alfa. Isso quer dizer que as novas funcionalidades não estão todas finalizadas. Na verdade, precisamos muito da ajuda para testar as funcionalidades anteriores que estão sendo unificadas (ECF, NFe, NFCe) para ter certeza que as novas como o SAT já podem ser o foco principal. Mas poucas pessoas tem dado retorno de estarem usando as funcionalidades anteriores e estarem tirando proveito dele...

Desconheço o problema do FB com índices. Poderia anexar os links que você encontrou? O que sei é que dependendo do tamanho e da quantidade dos índices, então realmente vai haver uma demora. Mas isso é natural, afinal a ideia dos índices é justamente consumir tempo antes fazendo o índices para diminuir o tempo da pesquisa depois. Poderia executar um "gstat -a" no BD e postar o resultado? Talvez eu possa encontrar alguma coisa para lhe dar alguma ideia. Se puder também, nesse caso, coloque também o SQL que causa a demora. EDIT: Desculpe, esqueci de pedir para fazer o acima com o BD em funcionamento. Não faça um backup/restore antes. Execute o gstat no BD em uso pelo cliente.

Cerca de 90 mil registros é pouco. Mas você tem que entender que não dá pra ler todos os registros sem ter uma demora. 790 MB o backup? Porque se for o BD, ele não é grande... Já tive problemas quando peguei o sistema atual da empresa para mexer. Em geral era a forma como o programa trabalhava com o BD. Por isso eu lhe perguntei se já mediu os tempos e detectou exatamente o quê fica lento. Não há como ajudar sem saber exatamente o que é lento.

Você deve estar com algum problema. Normalmente não é necessário ficar fazendo backup/restore num BD Firebird. Você já detectou exatamente o quê faz o BD ficar lento?

A MP4200 TH FI nem permite inserir mais de 300 itens.

Veja:

Você sabe dizer qual foi a última vez que atualizou antes dessa de hoje? Em caso negativo, poderia tentar fazer um "update to revision" voltando para uma revisão anterior que funcione? Talvez voltando de 60 em 60 revisões...

A maioria dos leitores, principalmente os USB, funcionam como um teclado. Então você não vai conseguir bloquear o teclado sem bloquear o leitor.

Obrigado pelo retorno.

Qual o modelo que você enviou para o arquivo?

Sim. Como eu disse antes, verifique com a certificadora - os manuais são outros. Pesquise no fórum pois já falaram sobre isso.

Qual o modelo da nota?

Pois é, então não tem necessidade de fazer uma reimpressão do cupom utilizando o ADM... A má notícia é que o ACBrTEFD foi feito especificamente para atender a comunicação feita ao imprimir um cupom. A boa notícia é que já foi dito ser possível fazer a comunicação nestes casos de recebimento não fiscal utilizando o ACBrTEFD. Só que não há nenhum exemplo neste sentido. Tente entrar em contato com a certificadora para obter informações sobre qualquer certificação neste sentido. Também procure no fórum mais informações e daí desenvolva com base nisso.

Estamos cansados de repetir aqui no fórum que tem coisas que devem ser geradas diretamente do BD.

Você leu o manual e comparou o modelo do registro com o que o manual diz sobre ele?

Por favor, não faça posts duplicados. Continue em:

Quando se paga com cartão a prazo, o cliente não volta daqui a 30 dias pra pagar fazer outro lançamento de pagamento TEF no cupom. O cupom já foi impresso, não dá pra refazer. Ele faz o pagamento no cartão na hora e "resolve com o banco" depois. Agora se o pagamento foi computado no cupom como crediário (não como cartão), então não houve transação TEF no cupom. Se mais tarde o cliente volta pra pagar a parcela do crediário com cartão, a aplicação pode fazer um recebimento não fiscal via TEF. Mas aí já é outra coisa, visto que não há impressão de cupom.