Re: BLOBS in the database

Gobsmacking is the only word that springs to mind. Astonishing is another.

Downloaded the freebie, and it does *everything* I wanted, and more. And I only had to write one line of code (and even I can manage that).

Oh, and the same 60+ image files loaded in around 1/20th of the time, and are currently consuming a mere 260K, instead of 100Mb+. Extraordinary. You live and learn, I guess.

Thank you *so* much for the tip. Now for the crunch question... I only want a single-seat developers licence, but how much are we talking? Tens or hundreds? Or worse? (I know I could email them, but since you're already in the know, it seems somewhat redundant!)

Regards
HJR

--
=============================!!=============================
The views expressed are my own only, and definitely NOT those of Oracle
Corporation
=============================!!=============================


"Exponent" <exponent_at_hotmail.com> wrote in message
news:c8997806.0105220308.6bd2665f_at_posting.google.com...


> 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