[firebase-br] Exceção: BLOB NOT FOUND

[Gladiston Santana]

A falha que mencionou pode ser por banco corrompido ou falha no software
que acessa os dados.
Quando é corrupção de dados não há como resolver senão backup/restore.
Agora a falha no software não fica muito evidente até que ocorra e seja
repetitivo com uma base que sabidamente está limpa de erros. Daí devemos
imputar a culpa no software, seja o lado servidor ou cliente.
Usando o IBO eu tinha mais desse problema até que na lista de discussão
alguém me informou alguns parametros/atualizações que resolviam a situação,
então as vezes o problema tá mesmo nos componentes de acesso ou modo de
usá-los.
Para entender melhor porque esse erro ocorre com os componentes, as suites
como IBX, DBX, Firedac, IBO,... a menos que você use algo como 'fetch_all',
elas paginam dados, isto é, leem um numero de registros e quando o cursor
alcança o limite então vai buscar os próximos dados no servidor.
Para economizar banda, inicialmente os blobs não são trazidos para a
memória, no seu lugar fica o ponteiro. Daí quando vão ser recuperados por
meio de um TMemoField, TBlobFIled ou o que valha, num dbgrid, dbedit,
dbmemo,... o ponteiro acionado para recuperar aquela informação, já deu
para entender né? O ponteiro(ou id) não tava lá como esperado, daí a
mensagem de erro. Isso pode acontecer porque algo na transação ou paginação
pode ter flutuado e a condição modificou-se de como era no inicio e o id do
blob não era mais aquele, em sumo, o ponteiro tornou-se invalido.

Em programação, você pode resolver isso por obliterar o blob do seu select
inicial e fazer um novo select apenas para o blob quando for exibi-lo ou
editá-lo, daí você traz a informação bem quente e sem paginação.

[]´s


Em qua, 27 de mar de 2019 às 10:54, Eliseu Corrona <
eliseucorrona em jbsoft.com.br> escreveu:

> Olá Gladiston, obrigado pelo retorno.
>
> A questão do backup/restore é o processo que estamos realizando para
> correção da exceção. O detalhe é apenas que não identificamos a causa
> correta da falha.
>
> Utilizamos DBExpress ainda. Devido a complexidade dos nossos processos
> não conseguimos ainda migrar de versão do Delphi e biblioteca de
> persistência, mas a ideia é sim migrar para o Firedac.
>
> Quanto a utilização de campos Blob, neste caso que citei, essa
> informação não é exibida. Ela somente é acessada no momento e que for
> necessário gravar dados ou consultar. Uso restrito e otimizado.
>
> Se conseguirmos identificar o que gera a falha, ficará mais fácil
> prevenirmos tal situação.
>
> Att.
>
> Em 27/03/2019 10:04, Gladiston Santana escreveu:
> > Olha colega, isso já aconteceu no passado remoto comigo muitas vezes e
> era
> > com o MSSQL.
> > No Firebird2 o pessoal reclamava bastante disso também.
> > Para evitar que seja realmente uma falha na estrutura, recomendo que faça
> > imediatamente um backup/restore do banco.
> > Não sei se está usando firedac (recomendo), mas se não estiver, faça com
> > que blobs só seja requisitados quando forem realmente necessários.
> > As vezes acontece de usa-los num select com apresentação num grid onde o
> > campo blob está oculto. Essa técnica é um desperdicio de recursos e fica
> > pior com o BDE, onde ele é incapaz de resolver situações de cache
> > (blobtocache) e praticamente insoluvel a não ser que faça o seguinte, o
> > resgate do blob deve ocorrer apenas quando o mesmo irá para a edição ou
> > estará visivel na tela, nessa hora o select do blob solitário deveria
> > ocorrer. Fazer desse jeito quando com persistência de dados e datawares é
> > desafiador, mas é mais performático do que carregar todos os blobs sem
> > necessidade porquehá suites de componentes (já citei o BDE) que tem
> > dificuldade em "pagear" os dados quando há blobs neles.
> >
> > []´s
> >
> > Em qua, 27 de mar de 2019 às 08:49, Eliseu Corrona <
> > eliseucorrona em jbsoft.com.br> escreveu:
> >
> >> Bom dia pessoal, tudo bem?
> >>
> >> Estamos passando por alguns problemas relacionados a corrupção de
> >> *campos blob*. A situação está ocorrendo de forma aleatória com alguns
> >> clientes nossos e ainda não identificamos a causa.
> >>
> >> Geralmente é assim. O cliente trabalha normalmente no sistema durante
> >> todo o dia. No dia seguinte, ao entrar no sistema ocorre a exceção *BLOB
> >> NOT FOUND* associado a uma tabela específica.
> >>
> >> A tabela em questão é bastante acessada e nela temos um campo Blob que
> >> recebe modificações frequentes. No caso, armazena um XML.
> >>
> >> Algum dos colegas teria alguma dica da possível causa do problema?
> >>
> >> Grato.
> >>
> >>
> >>
> >> ______________________________________________
> >> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> >> Para saber como gerenciar/excluir seu cadastro na lista, use:
> >> http://www.firebase.com.br/fb/artigo.php?id=1107
> >> Para consultar mensagens antigas:
> >> http://www.firebase.com.br/pesquisa_lista.html
> >>
> >
>


-- 
A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
na Melhoria Continua.

Em março de2018 migramos com sucesso para a nova versão da ISO 9001.

Somos a única Empresa Brasileira de Engenharia de Laboratórios com
certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
Fabricação e Instalação de Laboratórios.