Re: Storing JPG's as BLOB data type

hi Roger,

The advantage (pros) of using a BLOB you already know: It keeps things more organized. You can store the picture in the same record with the other relevant details, delete/purge them as one record, and never worry about your database & IFS directories getting out of sync.

The disadvantage (cons) is that the JPG data is only available via SQL. So you can't simply have a web page that refers directly to the JPG via an <img> tag... instead, a program/script has to run that will load the JPG from the file. Likewise, if you have a PC program that you're using to browse the IFS, you won't find your images, you'll have to extract them from the database first.

You don't have to "convert" the data (it's still the same exact stream of bytes) to put it into a BLOB... but you'll need to copy it from the STMF into the BLOB of the record.

This should be pretty trivial to do if you already have a list of the filenames in a database file. The pseudocode looks like this:

1) Read a filename
2) Fill in a BLOB_FILE structure with the filename, filename length, and file option.
3) Run an INSERT (or UPDATE) SQL statement to add it to the database
4) Delete the IFS file (assuming insert/update was successful)
5) Repeat steps 1-4 until there are no more filenames to process.

It really wouldn't be a big deal to write and run this program as a one-time-shot to get the data into the database.


On 7/6/2011 4:24 PM, Harman, Roger wrote:

I've been considering changing the data storage on one of our apps
that uses images. Currently, we store the images as JPG's and use a
file name reference in the database record. I was thinking about
storing them as BLOB's so the image always stays with the other data
or goes away when the record is deleted.

Has anyone done anything similar and any considerations (pro& con) I
should be aware of? Also, any references to converting several
thousand JPG's to blob (and vice versa) would be appreciated.


Thanks.