EMBarbosa

Bom dia. Comparando com o manual você conseguiu identificar quais dados não estão presentes na string gerada?

Só fique alerta pois, onde o PAF-ECF é aplicado, cupom vinculado só pode ser utilizado para transação TEF. Não sei em SP...

Talvez possa ser um problema do Firmware. Verifique se há alguma atualização para ele. Outra possibilidade, verifique se eles possuem uma DLL e como os valores são retornados pela DLL ou um programa de exemplo do fabricante.

Por favor, não faça isso. Crie um tópico novo para uma dúvida nova conforme as regras. Veja neste em especial a "2.2 - Permaneça no assunto".

Sim. Mas ficaria correto, leve, com menos uso do servidor e fácil de dar manutenção. Fora isso, o que você está mencionando não tem muito sentido. Quando você altera o valor de estoque de uma matéria prima não necessariamente deveria alterar o valor do estoque do produto. Mas se realmente quiser fazer do jeito proposto, utilize uma variável de contexto para verificar se a trigger já está sendo executada mais de uma vez.

Acho que seria uma melhor opção utilizar uma ou duas procedures para fazer as atualizações. Sobre o flag, como a atualização é em vários registros, talvez fosse melhor uma flag utilizando as variáveis de contexto.

Sobre esse caso 1, pode ser um problema semelhante ao que foi apresentado na função LFill. Vejam Talvez fosse bom um test case para validar a necessidade da alteração.

Ele pode estar sendo chamado nos eventos ou em outro local do seu aplicativo. Tente reproduzir o problema com o programa de exemplo. Se não acontecer, execute seu aplicativo, coloque um breakpoint no "FecharRelatorio" do componente e veja quem está chamando ele.

Até onde me lembro não há problemas no Firebird 2.5.x de variáveis de contexto.

Ele sempre deveria pegar os breakpoints usando F9. O atalho Shift+Ctrl+F9 é que executa fora do debugger.

Daniel, é melhor aumentar o tamanho da letra aí na parte onde diz: use apenas para testes. Tipo (use apenas para testes)

Para tentar corrigir você terá que ver exatamente a linha onde ocorre o AV, examinar o callstack e a mensagem exata de erro.

Não sei outras marcas, mas o emulador da Bematech também emite um erro se você tentar buscar dados da última redução Z mas não houver nenhuma redução Z. Diz que a memória da Redução Z está corrompida ou algo assim...

Principalmente no Delphi 7

Será que você não fecha a conexão e abre ela novamente em alguma circunstância? Isso faria com que as variáveis de contexto fossem zeradas. É possível que algumas de suas chamadas estejam sendo executadas ao mesmo tempo que você envia o comando para definir o valor da variável? Já tentou fazer um log do momento exato onde isso acontece e verificar o código está realmente utilizando a mesma sessão que deveria?

O erro parece ser por causa do caminho escolhido, veja:

Além do que o Daniel mencionou, qual a versão do emulador? Conseguiu identificar exatamente em qual linha acontece o AV (Access Violation)? Você tem um log do ACBrECF?

Em poucas palavras, isso depende do Estado. O funcionamento da NFC-e não exige o funcionamento de um PAF-ECF. Por isso o Estado poderia em tese dispensar o uso do ECF. Mas a NFC-e, embora seja muito mais simples de uso e use como base a infraestrutura da NF-e, pelo menos ainda, não tem a mesma agilidade de atendimento ao público e garantia de funcionamento em contingência. Isso fica claro quando lembramos como a qualidade da internet é instável em vários lugares. Assim, para evitar sonegações e garantir um atendimento ágil e de qualidade aos clientes, pode ser que o Estado prefira manter o PAF-ECF até que o sistema de NFC-e fique estável ou pelo menos propor a utilização dele em contingência. Como é uma decisão do Estado, não temos como ter certeza.

Você tentou com o programa de exemplo do ACBrECF, o ECFTeste? Este ECF possui alguma Redução Z emitida? Qual método você está utilizando para buscar os dados da Redução Z?

Se utilizar o programa de exemplo para avaliar o que precisa fazer, verá que não precisa achar equivalentes ao componente antigo. Precisará achar equivalentes ao que deseja fazer conforme os roteiros novos. E isso é o que está disponível, conforme o Régys disse acima.

Pelo que descreve, o erro é devido a consultas por meio de seções diferentes (não sei se seções é a palavra certa...). Enfim, fora regras no dispositivo que faz o balanceamento para garantir que seja utilizado o mesmo link para saída e entrada por máquina ou pelo menos por conexão site|máquina, eu desconheço qualquer outro meio de corrigir.

Veja o programa de exemplo, ECFTeste.

Só para tranquilizar os interessados no Git, eu planejo manter um repositório aberto que vai se comunicar com o SVN oficial. Daí quem quiser poderá utilizá-lo. Eu vou assim filtrar, compatibilizar e enviar ao SVN as alterações propostas. Se isso realmente ajudar outros a contribuir ao ACBr eu vou mantê-lo. Mas se burocratizar ainda mais, eu vou fechá-lo. Assim como o Daniel, eu quero que seja fácil o acesso. Vejo muitos usuários tendo problemas com um controle de versão aqui no fórum. A previsão é fazê-lo no primeiro semestre do ano que vem em caráter experimental. Mas antes, eu preciso terminar outras coisas que são mais urgentes. EDIT: link para um tópico

Particularmente, não vejo problemas com a implementação 1. Se ninguém for contra, você poderia fazer as alterações, testar e anexar aqui no fórum os arquivos para que a gente pudesse enviar ao repositório.

Envolveria muita alteração de código e muito trabalho para evitar problemas ao fazer o que você deseja. Além disso, não havia garantias que os registros seriam iguais e hoje ainda não há garantias de que vão continuar sendo. Por isso o mais simples na época foi fazer separado. Mas se quiser propor mudanças para facilitar, fique a vontade para isso. Depois você poderá anexar os códigos alterados e a gente vai analisar e subir para o SVN.