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