× 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.



... 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.

If you are already on release 7.1 just use the scalar function
GET_BLOB_FROM_FILE to insert a BLOB into a BLOB-column:

Insert Into MyTable
Values (Value1, Value2,
Get_Blob_From_File('/home/MyDir1/MySubDir/MyPricture.jpg'), ....);

... but Get_BLOB_From_File must be executed under commitment Control!!!

(In Release 7.1 there are also functions to get a LOB-Locator on a CLOB or
DBCLOB and XML-Documents
i.e. Get_CLOB_From_File, Get_DBCLOB_From_File, Get_XML_File)

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Scott Klement
Gesendet: Thursday, 07. July 2011 00:08
An: Midrange Systems Technical Discussion
Betreff: 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.