× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.