matheusguerra
-
Total de ítens
13 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por matheusguerra
-
-
8 minutos atrás, EMBarbosa disse:
Não quis dizer que você não tinha alterado. Na verdade, eu estava explicando o motivo do tempo ser menor quando a propriedade é false, já que você disse que não tinha nada na documentação.
Desculpa, não tinha prestado atenção.
8 minutos atrás, EMBarbosa disse:Não é isso o que a propriedade cachedUpdates faz?
Sim.
8 minutos atrás, EMBarbosa disse:De qualquer forma, talvez seja a hora de remover os componentes "DBDataAware"...
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. -
9 minutos atrás, Juliomar Marchetti disse:
Sinceramente o tempo e problemas que vai causar a seu cliente/usuário é o mesmo que programador sua aplicação para trabalhar corretamente na nuvem
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. -
1 minuto atrás, BigWings disse:
Fiz um teste com 100.000 alterações num TField do TFDQuery conectado em um banco na rede local e ficou num total de 56 ms.
Tem algum evento no OnChange ou OnValidate desse TField que possa estar consumindo banda?
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.
-
22 minutos atrás, EMBarbosa disse:
Isso acontece porque o evento OnCalcFields é chamado sempre que algum campo é alterado. Está na documentação, veja:
Já alterei a property AutoCalcFields.
2 horas atrás, matheusguerra disse:alterando a property TFDQuery.AutoCalcFields para false
22 minutos atrás, EMBarbosa disse:Isso acontece porque o evento OnCalcFields é chamado sempre que algum campo é alterado. Está na documentação, veja:
Não sei ao certo que tipo de documentação você quer encontrar. Contudo, é natural que um BD na nuvem vai demorar mais pra responder por causa da latência.
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.
Muito Obrigado pela atenção.
-
1 hora atrás, EMBarbosa disse:
O "Append" carrega outros registros para apenas depois fazer a inserção no final do TDataSet.
Se o problema for esse e você usar o "insert", possivelmente será mais rápido.
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.1 hora atrás, Juliomar Marchetti disse:Como assim na nuvem?
tu não colocou seu banco na internet e está acessando diretamente ele?
imagine o quanto de banda de internet vai comer seu sistema e na maioria paga por trafego de dados.
Sim na nuvem, consome sim bastante banda, mas nada fora do comum. Tem muitos que usam desta forma e no caso estou usando com o Firebird 3.0 que melhorou bastante com a compressão de dados. Tem a falta de tempo para converter tudo para um servidor em rest, mas com tempo vai convertendo.
-
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?
-
40 minutos atrás, Anderson Eccker disse:
Amigo, eles não podem cobrar a transmissão pois nem está disponibilizado para testes a versão 02.05
Provavelmente eles vao testar apenas a geração, estrutura e a assinatura digital.
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.
-
Danillo
Segundo a polimig onde vamos homologar ato cotepe 02.05, é para homologar validando a assinatura.
Este arquivo esta valido e feito pelo acbr.
-
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 fontes antigo, alterar o nome e fazer a tratativa pela minha aplicação, quando chamar a class do Daniel (ato cotepe 02.05) ou a antiga (ato cotepe 02.04), ou crio uma property versão nos fontes do Daniel e repasso aqui, fazendo a tratativa para as duas estruturas.
O que vcs acham?
Obrigado
-
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)), QTDE_EST), 9, 3) +//LFill(DT_EST, 'yyyymmdd') +sLineBreak;Desculpe, desconsiderem. -
Ou a quantidade mandamos negativa quando for e o componente seta esse campo?
-
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
privatefRegistroValido: boolean;fCOD_MERC: string; /// Código da mercadoria ou produto cadastrado na tabela a que se refere o requisito XIfDESC_MERC: string; /// Descrição da mercadoria ou produto cadastrada na tabela a que se refere o requisito XIfUN_MED: string; /// Unidade de medida cadastrada na tabela a que se refere o requisito XIfQTDE_EST: currency; /// Quantidade da mercadoria ou produto constante no estoque, com duas casas decimais.//fDT_EST: TDateTime; /// Data de emissão do DAVpublicconstructor Create; virtual; /// Createproperty RegistroValido: Boolean read fRegistroValido write fRegistroValido default True;property COD_MERC: string read FCOD_MERC write FCOD_MERC;property DESC_MERC: string read FDESC_MERC write FDESC_MERC;property UN_MED: string read FUN_MED write FUN_MED;property QTDE_EST: currency read FQTDE_EST write FQTDE_EST;end;Será que estou usando o componente antigo? Deve ser implementado esse campo?
TFDQuery.Append Lento
em Banco de Dados
Postado
Descobri, o problema é que tem o evento OnDataChange no TDataSource.
Falha minha deixar isso ter passado batido.