Re: BLOBS in the database

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
>
>
Received on Wed May 23 2001 - 12:13:40 CDT