Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

matheusguerra

Membros
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About matheusguerra

  • Rank
    Novato

Profile Information

  • Sexo
    Masculino
  • Location
    Uberlandia

Recent Profile Visitors

650 profile views
  1. Descobri, o problema é que tem o evento OnDataChange no TDataSource. Falha minha deixar isso ter passado batido.
  2. Desculpa, não tinha prestado atenção. Sim. Tem razão. Fiz uma aplicação de teste no mesmo cenário e o tempo foi 0 (Zero). Vou continuar aqui e se descobrir algo que estou fazendo ou entendendo errado posto aqui. Obrigado.
  3. Certo. Referente ao tempo. É uma aplicação muito grande e legada que passou por muitos programadores desde 1999. Vai demorar muito para migrar tudo para servidor rest. Em pesquisas, existem muitos casos de sucesso usando desta forma, não é o Oracle 12c, mas o Cantu brigou muito para melhorar o Firebird usando neste cenário. Com o firebird 3.0 com a compressão ligada, estamos trabalhando normalmente, parece local, mas veio essa questão que citei aqui no fórum.
  4. Não tem nenhum evento ligado em nenhum TField. Sim na rede local fica muito rápido, agora na nuvem acredito que vai até o SGDB e devido a latência tem essa pequena demora.
  5. Já alterei a property AutoCalcFields. Além da que você passou também olhei essa. http://docs.embarcadero.com/products/rad_studio/firedac/frames.html Sim, sei que não vai ter a mesma performance com o SGDB sendo consumido em uma rede local, mas os milésimos de segundo demorando que citei, está ao aplicar valor em um field do dataset, que está na memória. Ai vem a duvida, será que estar indo até o SGDB para fazer alguma validação? É possível não comportar desta forma? Um TFDQuery com 30 fields perde quase 3 segundos alterando dados na memória local. Muit
  6. Com insert a performance fica a mesma. A conta dos milésimo de segundos ocorre em qryCODITEM.AsInteger := 1; Acredito que o FireDac neste momento vai até o SGDB fazer alguma validação. Em TFDQuery.UpdateOptions já até coloquei a property FastUpdates = True. Com o SGDB na rede local, é muito rápido, já em cloud parece gastar o tempo de acesso ao servidor. Olhei a documentação do FireDac e não encontrei nada falando sobre, nem nos fóruns. Minha aplicação trabalha assim em muito lugares e perde um pouco devido a isso. Sim na nuvem, consome sim bastante banda, mas nada fora do co
  7. Append lento. TFDQuery ao aplicar valor em um field com SGDB na nuvem, consome 144 milésimos de segundos, alterando a property TFDQuery.AutoCalcFields para false, esse tempo chega a 071 milésimos de segundos. Usando o SGDB na rede local, o tempo fica 004 milésimos de segundos. Exemplo: qry.Append; qryCODITEM.AsInteger := 1; //Aqui fica lento com o SGDB na nuvem. Acredito que o firedac vai até o SGDB a cada alteração do field. Aguêm já teve cenário igual? Tem como melhorar?
  8. Certo, mas quando eu for transmitir em produção deve ser a versao 02.04, caso não altere o webservice para validar 02.05. Ai já altera a aplicação, vou tentar deixar gerando as duas versoes, para não ter esse problema.
  9. Danillo Segundo a polimig onde vamos homologar ato cotepe 02.05, é para homologar validando a assinatura. Este arquivo esta valido e feito pelo acbr. Estoque.xml
  10. Perfeito. Estou em processo de homologação que vai ocorrer no próximo dia 02/05/2017 agora com a polimig. Fui informado que o novo webservice vai começar a validar os arquivos na estrutura do ato cotepe 02.05 neste próximo mês de maio e a homologação deve ocorrer também com a versão dos arquivo 02.05. Com os fontes que foi passado pelo Daniel Simoes, vai validar a estrutura 02.05, meu medo e que, caso eles adiam a validação na estrutura do 02.05 a aplicação não vai conseguir enviar os arquivos, onde, se ficar sem enviar 10 de redução Z devo travar a aplicação. Pensei em pegar os font
  11. Desculpa, achei aqui no código que o componente mesmo faz isso. strRegistroE2 := strRegistroE2 + LFill('E2') + LFill(FRegistroE1.CNPJ, 14) + RFill(COD_MERC, 14) + RFill(DESC_MERC, 50) + RFill(UN_MED, 6, ifThen(RegistroValido, ' ', '?')) + LFill(ifThen(QTDE_EST < 0, '-', '+')) + LFill(ifThen(QTDE_EST < 0, (QTDE_EST * (-1)),
  12. Ou a quantidade mandamos negativa quando for e o componente seta esse campo?
  13. Bom dia galera. Vamos usar agora o componente PAF ECF ACBr. Estou implementando os relatórios PAF. Notei que no ATO COTEPE/ICMS 9, DE 13 DE MARÇO DE 2013 (http://www1.fazenda.gov.br/confaz/confaz/atos/atos_cotepe/2013/AC009_13.htm). O registro E2 deve enviar o campo 06 - Mensuração do estoque, onde, não esta implementado na classe TRegistroE2 = class private fRegistroValido: boolean; fCOD_MERC: string; /// Código da mercadoria ou produto cadastrado na tabela a que se refere o requisito XI fDESC_MERC: string; /// Descrição da mercadoria ou produto cadastrada na tab
×
×
  • Create New...