OldProgramer

Agradeço a sugestão Solivan, mas acho estranho supostamente ser forçado a usar transactions se um um simples update direto fica "suspenso" sem solicitação (com o Zeos não tinha esse problema, se eu dava um update xyz ele era efetuado - desde que sem concorrência logicamente - e fim de papo). Agora vira e mexe os usuários precisam fechar o sistema para uma atualização ser feita ou um deadlock ocorre sem que nenhuma transação tenha sido iniciada. Outra coisa bizarra que ocorre é num "while not eof" com uma sequência de dados, se "next" ultrapassa o rowlimit do fetch o eof fica true ainda que existam mais registros na busca... Se arrependimento matasse...

Usava o XE6 com Firebird 2.1 e tudo estava ok. Resolvi trocar pelo Firedac para poder atualizar o Firebird e nos normais antes da implantação foi tudo ok. Agora vira e mexe aparece usuário reclamando que fez isso ou aquilo, está no seu computador mas não no de outra pessoa. Nem estou usando transactions nem cache updates. Um simples pool de insert's ou update's fica como efetivado no local somente para este usuário e às vezes quando ele fecha o programa atualiza outras vezes não. Tem algum commit que deve ser dado ou parâmetro que deva ser utilizado? Grato por qualquer ajuda.

Eu estou tentando, mas o firedac do XE6 da uns erros muito estranhos... com o Zeos (7.1 que nem suporte oferece ao FB3) consegui acessar normalmente. O que vc está usando para acesso?

Boa tarde Edson. Para consultar os pedidos precisa ter a autorização não é? Ou seja, executar o login, gravar a seção, etc. Não precisa ter um server side rodando num https?

Opa xyberx, antes de mais nada parabéns aí pra vc e pro pessoal mais diretamente ligado à bagaça! Eu uso o XE6 e corrigindo uns detalhes aqui ou acolá pra instalar deu tudo certo. Estou testando e estudando o "troço" (no bom sentido!). Em debug eu fiz um teste fazendo um update sequencial registro a registro em um banco remoto (coisa banal, peguei uma tabela no remoto fiz um loop e atualizei registro a registro a tabela do server). Aconteceu uns erros de socket e dando continuar ele prosseguia fazendo sem aparentemente cair a conexão. Tive uns problemas com o Indy há um tempo atrás fazendo um sistema de comunicação via TCP que dava esses erros de socket eventualmente. Minhas perguntas (sem querer abusar da sua paciência) são: vc usa algo do TCP do Indy? Sendo sim ou não esses erros de socket que aparecem em debug são "normais"?

Marcos, eu usava o Zeos desde o D5 / Zeos6. Ele atendia bem até há uns 3 ou 4 anos, depois as atualizações começaram a rarear e melhorias então nem se fala. O último release foi bastante ruim. E está há tempos assim. Não houve escolha. De qualquer jeito, o Firedac não só atendeu perfeitamente, como veio muito bem com versatilidade e desempenho. Não só uso com o Firebird, como agora estou usando com MySQL e acesso direto à BD na net.

xyberx, migrei pro Firedac e realmente foi bem tranquilo. Vamos ver como será o feedback dos usuários... Olhei seu projeto e achei bem interessante. Vou estudar agora com mais calma. Obrigado pela atenção. Às vezes um "empurrãozinho" amistoso e bem intencionado vale mais do que 10 mil linhas de código.

Lazarinr, segui o conselho do colega xyberx e migrei pro Firedac. O aplicativo em questão tinha mais de 200 módulos (claro que nem todos tive que mexer) e gastei um dia pra sair do Zeos e ir pro Firedac. Aparentemente melhorou o desempenho, mas somente com os usuários me relatando mudanças consideráveis é que fico tranquilo. Mas é realmente bem simples sair de um pro outro.

Acho que vai ser o jeito. Obrigado pela dica xyberx!

Vale pessoal, mas estou usando o XE6 com o Zeos 7.1 (eu disse que o aplicativo foi migrado do D7/Zeos 6.6 a título de comparação base, ou seja, menor e mais rápido), e dou um build em release e fica exatamente igual ao build em debug. Não deveria diminuir nem que seja um pouco? O desempenho sofrível estou quase desistindo... talvez abandone o Zeos, mas tem uma pancada de coisa pra mudar, por isso a ' enrolação'.

É porque o Zeos para D7 só vai até esta versão e como fiz a migração para o XE6 (onde o Zeos vai até o 2.5, o 3 tá em beta) e alguns usuários ainda usam a aplicação antiga tive que manter a ver 2.1. Está sofrível. Se o colega lazarinr está me reportando isso no 2.5 tbm é uma péssima notícia.

Pesquisei uns tópicos por aqui e não vi referências. Talvez seja assim mesmo... Esse aqui foi um dos últimos: Depois que migrei minha aplicação D7 + Zeos 6.6 para XE6 + Zeos 7.1 o exe em release quase triplicou de tamanho e com desempenho inferior (com o firebird então pelamordedeus). Alguém sabe como posso melhorar esses dois fatores? Grato.

Prezados colegas, eu tinha (tenho) um aplicativo em D7 + Zeos 6.6 com Firebird 2.1 que rodava normalmente. Migrei a aplicação para o XE6 + Zeos 7.1 no mesmo Firebird 2.1 (porque algumas aplicações antigas exigiam esta versão) e o acesso aos dados ficou bem mais lento. Alguém usa Zeos + Firebird e teve alguma experiência desse tipo ou sugestão? Agradeço antecipadamente.

Bom, creio que resolvi o mistério. Fiz uma outra máquina virtual Win7/32 sem nada. Coloquei o demo do ACBr NFe gerado pelo D7 e o mesmo demo gerado pelo XE7. Instalei as bibliotecas e registrei o capicom tudo como de costume. O demo gerado pelo XE7 não abria mas dessa vez apareceu uma msg mais legível depois do crash (nos outros micrus havia o midas do D7 e aí não gerava mensagem da origem do erro): midas.dll está ausente. Baixei um midas.dll (sua descrição está como "Embarcadero Midas component pack"; daqui: https://pt.dll-files.com/midas.dll.html ) e beleza! Obrigado pela atenção.

A primeira coisa que pensei, mas no outro micro o meu gerado no D7 abre... Ontem reinstalei do zero inclusive com o XE7 e gerei o exe do demo do ACBr. A mesma coisa, roda na CPU que está o XE7 mas não na CPU do XP com o D7. E ambos estão com a última atualização do trunk2 e as mesmas DLL's... Estou travando a minha CPU cinzenta e mesmo achando que estou comendo bola em alguma bobeira não acho.

Apenas pra esclarecer o bizarro, segue a geração teste (sem nada a não ser um botão e o componente NFe) no meu XE6 (segunda img) e o teste no ambiente virtual XP que o antigo gerado pelo D7 roda normal (primeira img).

Prezados colegas, meu sistema de notas está funcionando normal ao ser gerado pelo D7, mas ao gerá-lo no XE6 ele gera uma exceção não específica logo na inicialização em qualquer micro que não seja o meu (Win 8/64+XE6). Testei em várias maquinas do cliente onde o outro gerado pelo D7 roda (Win XP, Win 7 32 e 64 e Win8) e a mesma coisa acontece. Eliminei todos os componentes e arquivos do XE6, atualizei o ACBr (ontem, 14/2), instalei do zero e gerei novamente e o problema persiste. Para eliminar qualquer dúvida de algo que tivesse comido bola na migração D7 -> XE6, peguei outro sistema (no XE 6) que não tinha nada do ACBr, coloquei o componente de NFe e não fiz mais nada, gerei de novo e acontece a mesma coisa. Alguém tem alguma ideia pra me dar uma luz? Agradeço imensamente.

Beleza Juliomar, tudo certo. Apenas para constar caso alguém consulte o mesmo caso, basta abrir o pacote da Danfe Fortes (ACBr\Pacotes\Delphi\ACBrDFe\ACBrNFe\DANFE\NFe\Fortes\ACBr_NFeDanfeRL.dpk), abrir o form contendo o modelo, editar e compilar. Depois "build" sua aplicação. Valeu!

Grato Juliomar. Passei para o Fortes e deu certo, apenas o CFOP que não sai o último dígito mesmo deixando as fontes em corpo 8. Eu nunca usei o Fortes, tem como mexer nesses modelos? Grato, Renato

Olá a todos. Depois de atualizar para o Trunk2 minha aplicação começou a dar problemas de impressão da NFe. Utilizando o arquivo de compatibilidade (DANFE.fr3) não dá erro mas os campos de faturamento não saem (no XML está ok). Utilizando o DANFEPaisagem.fr3 e DANFERetrato.fr3 dá um erro de classe e depois a primeira tela anexa. Utilizando suas versões "basic" dá um erro de classe e depois a segunda tela de anexa. Utilizo Delphi 7 com FastReport 4.9.72 em Win 7/64. Efetuei a atualização hoje (1/4/16), apagando todos os arquivos antigos e dando um build em tudo. Agradeço antecipadamente qualquer ajuda.

Atualizei do zero (14/12 às 16:50). O instalador continua sem a opção do GNRE e ressetando as opções do arquivo ini também não compila. Alterando o ini e fechando o instalador e o executando novamente dá certo. Foi mal...

Pessoal, o post do Regis indica para desmarcar o ACBrNFSe e ACBRGNRE. O "ACBrNFSe.dpk" tem opção para desmarcar mas o GNRE não. Está incluso em outro pacote? Grato.

Atualmente os certificados da Valid não instalam no XP, e nem sequer vem em pfx (não sendo possível usar o "InstaladorValid24"). Eles instalam pelo navegador diretamente na página da Valid e não se consegue exportá-los. Que inferno! No Win 8/64 e no 7/64 não estou conseguindo usá-lo. Alguém tem alguma opção diferente dos passos citados neste post?

Realmente essa Valid é uma lástima...

Deu certo. Marcação minha. Obrigado Juliomar.