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

Eliseu Corrona eliseucorrona em jbsoft.com.br
Qua Mar 27 13:34:39 -03 2019


Obrigado pelas informações Gladiston, muito relevante suas colocações.

É isso mesmo que havia entendido e pesquisado. No caso, o blob perdia 
sua "identidade" ou como vocês mesmo mencionou, perde a referência com 
seu ponteiro.

Até achávamos que esta corrupção podia ser devido a algum bug da 
biblioteca DBExpress que usamos ou de um dos nossos componentes de 
execução de scripts. Porém não conseguimos reproduzir o caso.

Vou verificar essas situações e atualizarei vocês aqui no grupo para 
futuras referências.

Abraço.

Em 27/03/2019 12:04, Gladiston Santana escreveu:
> 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 <mailto: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
>     <mailto: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 <http://www.firebase.com.br>)
>     - Hospedado em www.locador.com.br <http://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.
>
> 	
>



Mais detalhes sobre a lista de discussão lista