For now, it's just a storage issue. Currently the data is in MS-Access for a PC based ID card system (which can use ODBC once I move the data and can store the image in a BLOB in Access). I'm looking to move the data to the "i" so I can get an easier tie-in to HR. Eventually, I do plan on having the image available via browser from the green-screen HR app and a couple of others. Just need to verify the ID system will retrieve the BLOB column successfully.
Scott.... I know the byte stream stays the same (i.e.: untranslated); it was inserting it into the blob column that I was questioning. Your reminder about SQL type BLOB_FILE is what I needed. Then, I remembered your "RPG vs. the BLOB" article. A good reference.
Birgitta... your suggestion for SQL insert is great but I'm on V5R4.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, July 06, 2011 3:08 PM
To: Midrange Systems Technical Discussion
Subject: 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.
midrange.com
