Something like this should work...  (totally untested pseudo-code, your
mileage may vary)

<cfquery name="imageselect">select blob from tablewithimage</cfquery>
<img src="data:image/jpeg;base64,#tobase64(imageselect.blob)#" />


On Tue, Apr 2, 2013 at 3:19 PM, Mike Staver <[email protected]> wrote:

> Thanks for the input Teddy. Yeah, I did look at that - but it's my
> understanding that I would still need to dump the image out onto the file
> system before sending it out via the web server, right? I'm assuming there
> isn't a way around that.
>
>
> On 4/1/2013 2:21 PM, Teddy Payne wrote:
>
>> Mike,
>> Have you looked into using cfimage tag to reference, render, or
>> manipulate BLOB data?  If I recall, you can directly feed a database call
>> into a cfimge tag.
>>
>> Cheers,
>> Teddy
>>
>> Sent from my iPad
>>
>> On Apr 1, 2013, at 4:12 PM, Mike Staver <[email protected]> wrote:
>>
>>  I've been thinking about keeping all user-uploaded images in the DB for
>>> one of my projects. I know how I will work the process to get them into the
>>> DB and keep them off the hard drive. It would go something like:
>>>
>>> 1) Image uploaded to temp file system location from form post.
>>>
>>> 2) Image inserted into DB as blob.
>>>
>>> 3) Temp image removed from file system.
>>>
>>> Displaying the images is a bit more work I think. I assume I'd have to
>>> follow a similar process in reverse:
>>>
>>> 1) Extract image from DB to temp file system location.
>>>
>>> 2) Display it in HTML via web server as img tag.
>>>
>>> 3) Remove image after a certain period of time...
>>>
>>> Step 3 has me wondering: How long should I wait before removing the
>>> image from the file system? Meaning - in theory, I could remove the image
>>> before it would even have a chance to display via the web server, and I
>>> don't want that. Anybody have a good process to do this already? I'd love
>>> if there was a way to display an image directly from the DB, but I'm not
>>> aware of such a method. I'll probably just fall back on leaving those
>>> images on the file system as part of the display, and have my code check
>>> for their existence before retrieving them again. I didn't want to have to
>>> worry about the disk space, but I can't think of another way.
>>>
>>>
>>> ------------------------------**------------------------------**-
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.**edituserform<http://www.acfug.org?fa=login.edituserform>
>>>
>>> For more info, see 
>>> http://www.acfug.org/**mailinglists<http://www.acfug.org/mailinglists>
>>> Archive @ 
>>> http://www.mail-archive.com/**discussion%40acfug.org/<http://www.mail-archive.com/discussion%40acfug.org/>
>>> List hosted by http://www.fusionlink.com
>>> ------------------------------**------------------------------**-
>>>
>>>
>>>
>>>
>> ------------------------------**------------------------------**-
>> To unsubscribe from this list, manage your profile @
>> http://www.acfug.org?fa
>> For more info, see 
>> http://www.acfug.org/**mailinglists<http://www.acfug.org/mailinglists>
>> Archive @ 
>> http://www.mail-archive.com/**discussion%40acfug.org/<http://www.mail-archive.com/discussion%40acfug.org/>
>> List hosted by http://www.fusionlink.com
>> ------------------------------**------------------------------**-
>>
>>
>>
>>
>
>
> ------------------------------**------------------------------**-
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.**edituserform<http://www.acfug.org?fa=login.edituserform>
>
> For more info, see 
> http://www.acfug.org/**mailinglists<http://www.acfug.org/mailinglists>
> Archive @ 
> http://www.mail-archive.com/**discussion%40acfug.org/<http://www.mail-archive.com/discussion%40acfug.org/>
> List hosted by http://www.fusionlink.com
> ------------------------------**------------------------------**-
>
>
>
>

Reply via email to