Re: BLOBS in the database

Silly me! I'd thought that logo was merely an advert (and hence had ignored it).

Thanks.

Unfortunately, at that price, I think I'll hope for another solution to turn up. Thanks anyway
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:3b0befc4$1_at_lala.ammara...


>

> Howard,

> Glad this was useful, & thanks for your comments!

> The prices for all the license variants are on the website; go to

 'purchase' and follow the 'Soft-Shop'


> Logo.

>

> "Howard J. Rogers" <howardjr_at_www.com> wrote:

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

> >

> >

>