Ir para conteúdo
  • Cadastre-se

João Batista Costa

Membros
  • Total de ítens

    5
  • Registro em

  • Última visita

João Batista Costa's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • First Post
  • Conversation Starter
  • One Year In
  • Week One Done

Recent Badges

1

Reputação

  1. Boa noite, só pra dar o retorno... caso mais alguem passe pelo mesmo problema. Primeiro preciso dizer que ele só ocorreu pelo padrão que adoto de programação, onde não uso Querys para Inserir, Alterar ou Excluir, executo comandos direto no componente de conexão. Então o problema era ao executar um 'INSERT INTO TAB_XML ... ' e passando direto o .XML do componente do ACBr; por algum motivo que ainda não sei empacou nos 64Kb; A Solução veio quando testei uma dica passada pelo Thiago Amaral que fez através do padrão Query e ParamByName('XML').AsWideString; Acredito que o .AsWideString seja a chave, só sei que funcionou. Depois do teste bem sucedido, criei uma classe e incorporei ao sistema, e tudo funcionando de primeira; Vou anexar os comandos caso se interessem; E obrigado a todos que participaram desse tópco; Usando a classe TBlob. Código da Classe.
  2. Tambem estou procurando resposta no grupo especifico de FB, más como o assunto tbm é especifico pra armazenamento de XML de NFe gerado pelo ACBr, acreditei que alguem já tivesse passado por esse problema aki nesse forum, e se não passou, com certeza pela limitação do campo ou tipo de configuração, vai passar... Ou seja acreditei que seria util tbm no Forum do ACBr... Descupem se não consegui me fazer entender... Talvem se tivesse colocado no titulo apenas "Erro ao armazenar XML Grandes de NFe gerada pelo ACBr em banco de dados", seria melhor entendido... Más já estou fazendo testes com outros bancos, MySQL e Postgree, caso nesses bancos não aconteça o erro, volto a postar pra que se no futuro alguem que já armazena em seu banco de dados o XML de NFe gerado pelo ACBr com mais de 64Kb tenha o mesmo problema, consiga uma luz...
  3. Se fizer uma quebra de linha em qq ponto o XML se torna inválido... ai se perde totalmente o sentido de guardar o XML em banco, pra se ter um backup, não só do arquivo fisíco e ainda poder compartilhar em diversas máquinas da rede... A questão não é guardar o XML por guardar, ele tem que se manter integro e valido. A questão é o campo Blob do Firebird 3.0... ele tem ou não a opção de ter um arquivo com mais de 64Kb ...??? o manual diz que se for sub_Type 0 seria sim... más mesmo criando com sub_type 0 não grava se tiver mais de 64Kb.
  4. Estou com o mesmo problema, e não sei se conhecem campo Blob más não tem em lugar nenhum pelo menos no IBExpert onde podemos informar o tamanho máximo de caracteres, tem apenas o Sub_type 0 ou 1 e o Segment Size que o padrão é 80, más que acredito seja apenas pra alocação de blocos porque mesmo 80 esta permitindo gravar até 65535 bytes; A única diferença para o Thiago é que estou usando o sub_type 0, porque estudando achei essa diferença: O SUB_TYPE 0 é usado para armazenar dados binários maiores que 64 KB O SUB_TYPE 1 é usado para armazenar dados binários menores que 64 KB.
  5. Tentei varias combinações de Sub_type com o Size e não consigo gravar um XML que tem mais de 80Kb. Sempre aparece o Erro: [FireDAC][Phys][FB]Dynamic SQL Error SQL error code = -104 String literal with 82343 bytes exceeds the maximum length of 65535 bytes
×
×
  • 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.