Ir para conteúdo
  • Cadastre-se

matheusguerra

Membros
  • Total de ítens

    13
  • Registro em

  • Última visita

Últimos Visitantes

814 visualizações

matheusguerra's Achievements

  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. Muito Obrigado pela atenção.
  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 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.
  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 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
  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)), QTDE_EST), 9, 3) + //LFill(DT_EST, 'yyyymmdd') + sLineBreak; Desculpe, desconsiderem.
  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 tabela a que se refere o requisito XI fUN_MED: string; /// Unidade de medida cadastrada na tabela a que se refere o requisito XI fQTDE_EST: currency; /// Quantidade da mercadoria ou produto constante no estoque, com duas casas decimais. //fDT_EST: TDateTime; /// Data de emissão do DAV public constructor Create; virtual; /// Create property 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?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.