Storing animated .gif images

The following code throws the error indicated in the code. Apparently
this only appears to happen with animated gifs. Other image formats;
jpg, etc., are ok. A VB version of this code, which also uses ADO, works
w/o any problems.

require ‘win32ole’

ADTYPETEXT = 0
ADTYPEBINARY = 1

ADSTATECLOSED = 0
ADSTATEOPEN = 1
ADSTATEEXECUTING = 4
ADSTATEFETCHING = 8

ADOPENKEYSET = 1
ADLOCKOPTIMISTIC = 3

begin

imageFile = “dj.gif” #-- this is an animated gif!

st = WIN32OLE.new(“adodb.stream”)
st.Type = ADTYPEBINARY
st.Open
st.loadFromFile(imageFile)

puts(“Size of image file: #{st.size()} bytes”)

oCn = WIN32OLE.new(“adodb.connection”)
oCn.open(“Provider=sqloledb;Data Source=(local);Initial
Catalog=xxxxx;Integrated Security=SSPI;”)

oRs = WIN32OLE.new(“adodb.recordset”)
oRs.open(“SELECT * FROM xxxx”, oCn, ADOPENKEYSET, ADLOCKOPTIMISTIC)

oRs.addNew()

#-- store the name of the image file
oRs.fields(“imageFile”).value = imageFile

#-- throws the following error when the next line is executed
=begin
OLE error code:80040E21 in Provider
Multiple-step OLE DB operation generated errors. Check each OLE DB
status value, if available. No work was done.
HRESULT error code:0x80020009
Exception occurred.
=end
oRs.fields(“imageBinary”).value = (st.read().to_s())

oRs.update()

rescue Exception => ex

puts(“Exception: #{ex.message()}”)

ensure

#-- close and release recordset and database objects
unless oRs.nil?
unless oRs.state == ADSTATECLOSED
oRs.close
end
oRs = nil
end

unless oCn.nil?
unless oCn.state == ADSTATECLOSED
oCn.close
end
oCn = nil
end

unless st.nil?
st.close()
end

end

Patrick S. wrote:

The following code throws the error indicated in the code. Apparently
this only appears to happen with animated gifs. Other image formats;
jpg, etc., are ok. A VB version of this code, which also uses ADO, works
w/o any problems.

<big snip>

I guess I’ve answered my own question… an animated gif file is
actually several layered images. No bloody wonder I was getting the
aforementioned error when I attempted to store it in the SQL Server
table. On the brighter side of things, I’ve stumbled across a way to
store and retrieve other binary files; specifically .jpg’s, in a table,
w/o resorting to using the ADODB.Stream object. If there’s any interest,
I’ll post the code.

Patrick S. wrote:

I guess I’ve answered my own question… an animated gif file is
actually several layered images. No bloody wonder I was getting the
aforementioned error when I attempted to store it in the SQL Server
table. On the brighter side of things, I’ve stumbled across a way to
store and retrieve other binary files; specifically .jpg’s, in a table,
w/o resorting to using the ADODB.Stream object. If there’s any interest,
I’ll post the code.

That’s not exactly correct. It’s still only 1 file, and you couldn’t
split the file at several points and end up with whole images.

An animated gif is indeed several image pieces in a single file, but
there’s no reason trying to store that file should break anything.
There no ‘EOF’ markers or any crazy thing in the middle of the file.

William C. wrote:

An animated gif is indeed several image pieces in a single file, but
there’s no reason trying to store that file should break anything.
There no ‘EOF’ markers or any crazy thing in the middle of the file.

Agreed. My assumption was just a stab in the dark because I could come
up with no other explanation. Although I don’t have time to test it
right now, my guess is that if the field were defined as a “binary”
datatype, vs. an “image”, it would probably work okay.