Re: BLOBS in the database

The problem that you're experiencing is due to Access creating an uncompressed 'Preview' version of the image that can commonly be 10 times the size of the original jpeg. All this is then wrapped in OLE Headers, which can introduce other problems such as extracting the image from this undocumented format, viewing images on systems that don't have the correct OLE Server applications registered etc.

We offer a bound image control that overcomes these problems and adds a number of useful features for handling images in databases (either stored in tables or as external files). You can have the control resample the images as you load them to create multiple purposed images, such as main, thumbnail, print and archive, all at different resolutions and compressions. You can also obtain the image dimensions for web-publishing type applications. You can integrate directly with digital cameras and scanners, and you won't suffer from the OLE 'bloat' - the images will occupy exactly the same amount of space as they would as files.

If this is of interest you can download the control, samples and documentation from www.ammara.com

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:<3b09e49a_at_news.iprimus.com.au>...
> Am I doing something horribly wrong here? I have around 100 JPEGs I want
> stored within the database (ie, as a BLOB, not merely a BFILE). Not one of
> these pictures is larger than around 80K. I've just loaded 50 of them, and
> I'm up to 106 *MEGS* of storage.
>
> I haven't done much work with BLOBS before, and I expected a bit of
> fluffiness with these things, but not quite so fluffy that I need to buy a
> new hard disk to complete the project, thanks very much!
>
> 8.1.7 on W2K, graphics are being loaded via an OLE Linked object frame in
> Access, via ODBC. I'm using an 8K block.
>
> I've seen this same behaviour on, >cough<, SQL Server 2000, so I suspect
> it's an intrinsic feature of the way these things are stored internally, but
> I'm surprised if so that it appears so *very* inefficient. Any suggestions
> for different ways to go about this, gratefully received. The thing is,
> after this I'm scaling up to around 8000 graphics, some rather larger, and
> the whole point is that I do not want 8000 separate JPEG files floating
> around on my hard disk.
>
> Where are the good developers when you need one, huh??!
>
> Regards
> HJR
Received on Tue May 22 2001 - 06:08:41 CDT