-
Total de ítens
9.351 -
Registro em
-
Última visita
-
Days Won
117
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que EMBarbosa postou
-
Ser no applyUpdates não quer dizer nada. Esse método faz tanta coisa, que você não sabe o motivo real da lentidão. Por isso um profiler é a melhor ferramenta... Só insisti nisso porque você está indo na contramão de todos os benchmarks que vi sobre o assunto. O FireDAC desbanca o dbExpress em muito. A ideia de fazer o sql era apenas para saber sobre a velocidade mesmo. Afinal se com o SQL puro não ficasse mais rápido, o problema era o BD. Agora, se você está utilizando TClientDataset então tem outras coisas envolvidas. A dinâmica é muito diferente. Tem coisas que o TClientDataSet só faz no ApplyUpdates. Bom, não tem sentido eu ficar insistindo em algo que você não quer fazer. Mesmo porque não sou eu quem tem que lidar com os problemas. Só falei o que é minha opinião particular, de uma pessoa que já lidou com vários problemas de lentidão assim. Por outro lado seria falso da minha parte não lembrar que DBexpress é considerada tecnologia obsoleta
-
Já está no radar do Daniel para resolver. Mas se um de vocês puderem anexar o arquivo alterado facilitaria a análise.
-
Rapaz, usar os profilers é muito simples. Dá uma chance pra eles. É o tipo de ferramenta que depois de aprender a utilizar te abre uma nova visão das coisas. Mesmo uma tabela desse tamanho, se você está apenas inserindo um novo registro, o tempo gasto deveria ser bem pequeno. Você pode verificar isso executando o SQL diretamente. A menos que você esteja pensando em adotar um ORM como o mORMot, sugiro você tentar descobrir o problema e resolver.
-
Se resolver, por favor, anexem o arquivo alterado para que seja avaliado.
-
Você precisa verificar com o pessoal do suporte do DTEF o motivo da DPOSDRV.DLL não ter a função IdentificacaoAutomacaoComercial. Talvez essa dll esteja desatualizada.
-
Visto que está disposto a pagar, talvez queira colocar um tópico na área de classificados. Daí talvez alguém com experiência possa te ajudar.
-
Olá, Acho que não tem uma regra sobre isso. Na verdade o roteiro para NFC-e, até onde me lembro, é exatamente o mesmo para impressoras não fiscais. Contudo, eu sugiro você confirmar a transação TEF primeiro. Assim, caso o pagamento TEF não seja confirmado você não precisará alterar/cancelar a NFC-e que já transmitiu. Imagine que o cartão não passe e você já transmitiu a NFC-e com a forma de pagamento tipo TEF? Ainda tem que você precisa preencher alguns dados da NFC-e com detalhes da transação que só vão estar disponíveis depois. Além disso, caso tenha que fazer algum tratamento de contingência, a parte do TEF já foi confirmada. Acho que você poderia usar o evento onDepoisConfirmarTransacoes pra esse objetivo. A lista de respostas pendentes é adicionada na ordem que são feitas as chamadas. Então a última da lista é a última que foi feita... Você pode dar uma olhada nos seguinte tópico e no tópico que ele menciona: Se não estiver usando o SiTef tem outros tópicos sobre o assunto como: e também esse: https://www.projetoacbr.com.br/forum/topic/37672-como-capturar-os-dados-do-acbrtefd/
- 1 reply
-
- 1
-
-
Que bom que resolveu. Muito obrigado pelo retorno. Bom trabalho por aí.
-
E você tem certeza que não está vindo nenhum registro? Em caso afirmativo, eu sugiro você utilizar algum profiler. É melhor você medir exatamente onde está a demora que a gente ficar especulando. Talvez queira tentar o dbgSpider, ou o asmprofiler, ou ainda o Sampling Profiler.
-
Não sei de qual tipo de Dataset é o componente TB10000, mas geralmente PacketRecords não quer dizer quantos registros você vai puxar do BD. Apenas quantos vai puxar por vez. Então setar ele como 0 não vai necessariamente impedir de puxar todos registros da tabela. Bom, no código está apenas o Post e o ApplyUpdates. Qual método do componente você está utilizando para abrir um novo registro? Insert? Append?
-
Depende da forma que você faz a gravação. Por exemplo, se estiver carregando dados da tabela ao gravar, isso pode acontecer.
-
O gerenciador gpTefDial funciona diferente do gpCliDTEF. O gerenciador gpTefDial funciona por troca de arquivos como era comum há alguns anos quando a maioria dos comércios usavam TEF discado. Talvez eles tenham atualizado a aplicação TEF e alterado o modo do gerenciador trabalhar e por isso parou de funcionar. Independentemente disso, quaisquer um desses eventos são demonstrados nos aplicativos de exemplo. Você pode verificar a implementação neles. Mas aqui vai uma explicação rápida: OnObtemInformacao é um evento que trata as situações onde o Gerenciador do TEF está obtendo as informações do usuário. Então você deve criar uma tela para obter essa informação do usuário e retornar ao gerenciador TEF. Por exemplo: Qual a senha do Administrador? Em quantas vezes vai dividir? Qual o valor da taxa de embarque? Etc... ExibeMenu é um evento que gera para o usuário um menu com várias opções para que ele escolha uma. Assim você deve criar uma tela que mostre as opções e permita ele escolher uma. Por exemplo: É Crédito, Débito, Alimentação? É parcelado ou a vista? Dá uma olhada no aplicativo de exemplo que deve ficar claro como é simples fazer uma implementação dessas.
-
Veja bem, o seu log diz que a compilação do ACBr_Comum foi "um sucesso". Veja o log apenas a parte relevante: 29921 lines, 0.30 seconds, 121624 bytes code, 14861 bytes data. Compilation success Pacote "ACBr_Comum.dpk" compilado com sucesso. Então, pelo menos em teoria, o arquivo BPL deveria estar sendo criado. Mas se isso não está acontecendo, então você não vai conseguir compilar os outros pacotes pois eles dependem do ACBr_Comum. Talvez tenha que começar a avaliar se seu Delphi está instalado corretamente, se não está com algum conflito com o sistema operacional, se algum antivírus ou antimalware não está entrando em conflito. Em último caso, tente compilar e instalar os pacotes manualmente.
-
Que isso. Agradecemos o retorno. Bom trabalho por aí.
-
Olá, Esse código não parece ser do componente de SAT. Poderia verificar onde está definida essa variável 'AliqICMS' e qual o tipo dela? Pois ela parece estar definida como Integer.
-
Por favor, nos dê um retorno se conseguiu resolver.
-
Ficamos felizes em ajudar. Temos uma política de apenas um assunto por tópico. Por isso, por favor, da próxima vez crie um novo tópico para uma nova dúvida. Note que essa mensagem de erro foi interceptada pelo debugger do Delphi. Mas ela é originária do sistema operacional. Está dizendo que não foi possível criar o arquivo por causa de seu caminho ou nome. E isso fica evidente no nome do arquivo na mensagem, veja: "C:\uniquesystems\teste.txt " Tem um parágrafo no nome do arquivo. Isso não é permitido. Não sei como você está passando o nome para o componente, mas investigue isso daí.
-
Não vejo como problema. Na verdade isso indica que várias coisas estão certas. Podemos então procurar o que não está. Essa é a linha do seu projeto. É necessário que você a coloque por inteiro. Tente colocar um breakpoint nessa linha e depois ir apertando F7 para seguir dentro do código do componente até descobrir qual linha gera o AV (Access Violation). Isso apenas indica que o caminho que o código seguiu não gera o Access Violation. Talvez porque ele é gerado após a validação das alíquotas.
-
O que está mencionado na sua imagem me parece ser sobre a EFD ICMS/IPI, ou seja o SPED Fiscal. Sendo assim, o componente para te ajudar a gerar o arquivo é o ACBrSPEDFISCAL.
-
Acredito que está havendo alguma confusão na sua máquina. Veja que no log do ACBrInstall que você anexou não está mencionando a pasta trunk2 como você disse acima que existe: Compiling package C:\ACBr\Pacotes\Delphi\ACBrComum\ACBr_Comum.dpk "C:\Program Files (x86)\Borland\Delphi7\bin\dcc32.exe" "C:\ACBr\Pacotes\Delphi\ACBrComum\ACBr_Comum.dpk" Se você não conseguir descobrir o motivo dessa diferença, talvez tenha que apagar a pasta C:\ACBr e remover o ACBr completamente do Delphi antes de tentar fazer uma nova instalação.
-
Da mesma maneira que faria com outros TListBox não funciona? Usar a propriedade Items e o método IndexOf.