-
Total de ítens
13 -
Registro em
-
Última visita
Últimos Visitantes
814 visualizações
matheusguerra's Achievements
-
Descobri, o problema é que tem o evento OnDataChange no TDataSource. Falha minha deixar isso ter passado batido.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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. Estoque.xml
-
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
-
Relatório Paf - Registro E2
matheusguerra replied to matheusguerra's tópico in Legislação Fiscal e Tributária
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. -
Relatório Paf - Registro E2
matheusguerra replied to matheusguerra's tópico in Legislação Fiscal e Tributária
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 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?