OldProgramer
-
Total de ítens
88 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por OldProgramer
-
-
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"?
-
7 horas atrás, Marcos Gerene disse:
Bom dia, me desculpe a intromissão, eu hoje não programo mais em Pascal ja faz um tempo (migrei para C#, tenho apenas uma pequena aplicação em Lazarus ainda),
logo minha opinião pode estar defasada, então não leve como verdade, mas é interessante ponderar.
Eu já programei em Delphi 5 com paradox (usando BDE) ai migramos para Firebird com IBOConsole no Delphi 7 e depois DBExpert (ou algo assim, não lembro o nome) para o Delphi 2010, em todos foi usado o que a Borland (depois Embarcadero) "sugeria", até que eu sai da empresa e quis "abandonar" o Delphi para trabalhar com C#, restando apenas algumas pequenas implementações em Lazarus justamente por causa do ACBr.
Bem, repare que em todas as minhas mudanças de tecnologia ou evolução do código minha ferramenta de acesso a banco foi praticamente jogada no lixo pq era o que dava pra ser feito... ai a minha pequena aplicação usei o Zeos que era um componente de terceiros e opensource, nunca mais tive que reescrever minha camada de acesso a banco... tudo bem que estou falando de lazarus, mas "da no mesmo" que o Delphi neste caso...
Bem, depois de todo esse bla bla bla segue meu conselho: Não use Firedac. Não estou dizendo ser uma má ferramenta, eu sequer a conheço, mas não confio em uma ferramenta que amanhã pode ser descontinuada... eu manteria a versão 6.6 do Zeos e reportaria à comunidade o problema e esperaria sair uma versão 7.2 ajustada...
Como to "fora do mercado" de Pascal e não conheço o Firedac posso ter falado muita besteira, mas eu realmente tenho um pé atras com essa situação, eu "abandonei" o Delphi porque não confiava em seu futuro, mas se eu ficasse nele eu usaria apenas componentes opensource que poderiam ser adaptados para uma outra ferramenta (leia-se Lazarus)... se bem que eu usaria algum ORM open source existem ferramentas boas para tal tanto para Delphi como para Lazarus o que te deixaria mais livre ainda... hoje eu uso ADO.Net pq eu vim do Delphi pro C# então me faltou "malicia" na época, hoje eu usaria NHibernate (e não EntityFramework pelo mesmo motivo do Firedac), o que não faria gde diferença pq o NHibernate usa o ADO.Net por trás, mas ai seria "problema do componente" fazer uma eventual mudança...
Abraços
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.
-
Em 2017-6-7 at 13:45, lazarinr disse:
OldProgramer
Estou tendo o mesmo problema porém no Firebird 2.5
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.
-
5 horas atrás, xyberx disse:
Cara conselho, Minha package o REST Dataware eh para Delphi's Novos e Funciona com FireDAC, em rede local ela é maravilhosa e pela Internet também, vc não precisa mudar nada para trabalhar local e pela Internet, dá uma olhada pq ontem foi postado um conversor de ZEOS para REST Dataware então você conseguiria migrar normalmente sem muito esforço, além de no Servidor de Banco vc poder usar o FireDAC o Delphi nativo. VLW.
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'.
-
Em 2017-6-1 at 08:42, Juliomar Marchetti disse:
A pergunta que vou te fazer é a mesma que o mantenedor do Firebird iria te fazer!
Poque ainda está usando a versão 2.1 e não fez a migração para a mais recente?
É 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.
-
Em 15/02/2017 at 13:26, Juliomar Marchetti disse:
Dll!
lembre-se agora ele pode ser mudando de openssl para capicom em tempo de execução você colocou as mesmas no micro e também registrou as do capicom?
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.
-
1 hora atrás, Juliomar Marchetti disse:
Sim tem! ele é dentro de um form ! deve abrir ele e alterar
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!
-
1
-
-
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...
-
1
-
-
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?
-
Eu ja pedi a todos clientes que ninguem compre este certificado..
Realmente essa Valid é uma lástima...
-
Deu certo.
Marcação minha.
Obrigado Juliomar.
-
1
-
Firedac não grava às vezes
em Banco de Dados
Postado
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...