|
I never have quite figured out why one needs a blob field when you can just reference a file with a much smaller field. I'd love to hear reasons. Sal, nice site! Brad > -----Original Message----- > From: Sal Stangarone Jr. [mailto:sals@MRC-PRODUCTIVITY.COM] > Sent: Friday, May 04, 2001 1:27 PM > To: MIDRANGE-L@midrange.com > Subject: RE: BLOB picture application > > > If you want, you can see an example of this on our web site. > > http://crazybikes.com/employees/I00230GC.mrc?K001=A1040&@SMLNK=Y > > In this case the picture is stored on the IFS and the > application is written > in CGI. We just have a file on the AS/400 that references the picture > location with the product number. This is really just one > way of attacking > this and as you mentioned there are others. One of the > advantages to this > approach is the pictures can be stored on a separate machine > so you're not > using expensive AS/400 dasd to store graphic images. Feel > free to contact > me if you'd like additional information. > > Sincerely, > > Sal Stangarone Jr. > michaels, ross & cole, ltd. > > Phone: 630.916.0662 > Fax: 630.916.0663 > > > > > -----Original Message----- > From: owner-midrange-l@midrange.com > [mailto:owner-midrange-l@midrange.com]On Behalf Of afvaiv > Sent: Friday, May 04, 2001 12:38 PM > To: MIDRANGE-L > Subject: BLOB picture application > > > Hi folks, I am starting to analyze/design an Application for AS/400 > dealing with images (pictures). Let's say, something like > being able to > hold the employees picture (like an ID card) along with normal data > (name, address, etc). The goal would be to be able to > - show that picture along with the data in some sort of query, > - print out the ID card with the picture > I think I have more questions in my mind than real knowledge. > So, before > I write down some questions, let me outline what "I think" I know. > > - UDB400 allows me to include BLOB data in a DB record, either in the > form of the BLOB data itself, or as a "link" to some place where the > picture would be stored. > - RPG cannot access either one. This type of data can only be accessed > thru SQL > - I will not be able to display/print pictures from any "normal" (RPG, > COBOL,..) program > > I was thinking of saving each person's picture somewhere > within the IFS, > or even in a NT Server, but I think that's not the point here. Let's > asume each picture is in .bmp format, and is identified by > the person's > ID number, e.g.: 12345678.bmp. > > Asuming all the above are true, some questions follow: > > - Do I have to use some type of client/server application, e.g. > VisualBasic or Java to be able to use it as intended? If not, > how could > I show/print the pictures along with other data? > - If client/server model is indeed needed, what's the benefit > of keeping > the "link" to the picture as part of the record? I mean, if the client > program requests the persons' data, the ID number could just > as well be > used to load the picture from where it is stored (NT Server or > whereever). So, why would I need a field of "link" type? > - What's the benefit of SQL being able to access BLOB type data if, > after all, we cannot deal with it, in the AS/400 environment, in any > way? I can only think of returning it as part of the results being > received from a stored procedure, but then the previous > question applies > as well and would make it useless. > > Well, I think I just have a full mess in mi mind. Don't know where to > start with... Any ideas or experiences? > ----------------- > Antonio Fernandez-Vicenti > afvaiv@wanadoo.es > > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.