Gravando imagens e lidando com Streams

Artigo extraído do site: www.bufaloinfo.com.br

Autor: Dennes Torres (dennes@bufaloinfo.com.br)

Gravando imagens e lidando com Streams

No artigo anterior desta série vimos que podemos exibir imagens de bancos de dados Access. Mas foi mencionado que não seria possível exibir Gif's que houvessem sido inseridas no banco access através de um form access comum.

Como então podemos gravar gif's em banco access e recupera-las posteriormente ?

Vamos fazer um pequeno exemplo de gravação de uma Gif em ASP. Para realmente tornar esse exemplo útil ele deverá estar associado a uma aplicação que faça upload de arquivos, portanto sugiro ler nosso artigo sobre upload de arquivos com ASP. Porém o exemplo que faremos utiliza o ADO, portanto pode também ser codificado em VB.

Para fazer a gravação da imagem no banco de dados devemos resolver 2 problemas : 1o, como ler a imagem, 2o como gravar esses dados binários em um campo.

Vamos supor que a imagem já esteja gravada em disco. Ela poderia ser o resultado de um upload, por exemplo. Para ler essa imagem vamos utilizar um objeto chamado Stream. Esse objeto faz parte da biblioteca do ADO, surgiu a partir da versão 2.5 e facilita bastante o trabalho de ler um arquivo do disco, tal como o caso da imagem.

Com relação a gravação da imagem não poderemos fazer uma instrução INSERT, como seria o recomendável para mantermos a performance da aplicação. Para gravarmos a imagem em um campo deveremos utilizar o método AppendChunk, método do objeto Field do ADO. Isso significa que teremos que ler um recordset antes de fazer a gravação.

O RecordSet que iremos ler não precisará conter registro algum, já que nosso objetivo é gravar, não ler. Assim sendo, para otimizar a performance do banco podemos colocar no SELECT uma clausula WHERE absurda que fará com que nenhum registro seja retornado. Se colocarmos algo como Nome='1234' ainda assim teremos uma perda de performance, pois o banco terá que procurar entre os registros para verificar se existe alguém chamado '1234'. Porém se definirmos a clausula WHERE como 1=2 então não termos perda de performance pois o banco sabe que 1 nunca será igual a 2 e portanto nem se dará ao trabalho de procurar isso entre os registros.

Vamos supor que temos um banco chamado imagem.mdb com uma tabela "teste" que possui um campo autonumber e um campo IMAGEM que é do tipo OLE Object.

Veja como fica o código :

<%
dim cn,img
set cn=createobject("adodb.connection")
set rs=createobject("adodb.recordset")
cn.open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\dados\imagem.mdb;Persist Security Info=False"

dim x
set x=createobject("adodb.stream")
x.type=1
x.open
x.loadfromfile("C:\imagens\first.gif")

rs.open "Select * from teste where 1=2",cn,3,2

rs.addnew
rs.fields("imagem").AppendChunk(x.read)
rs.update
rs.close
set rs=nothing
set x=nothing
cn.close
set cn=nothing
%>

A linha x.type=1 indica o tipo de informação que o stream irá ler : dados binários.

Um código simples : Abre-se a conexão, cria-se um stream e usa-se este stream para ler uma gif do disco, recupera-se um recordset vazio, utiliza-se addnew para acrescentar um registro e appendchunk para fazer a gravação da imagem. Em seguida grava-se, fecha-se e destroi-se todos os objetos.