Very Computer

I would have thought so myself. Our network has a Netgear ND520 20M network
attached storage 'server'. I changed from storing in blobs to individual 5 -
15K jpegs and the disk space went way down. It turns out that the cluster
size on this server is 512K! Every 5K jpeg takes up a half meg of storage
space on the disk. What a waste.

Jim Margarit

David,

In Access, as well as a few other DB's that I am aware of, the graphic is not
stored in the database itself, but rather in a separate file which is simply a
sequential byte stream of graphic after graphic.  The contents of the graphics
field in the database record itself contain the relative byte offset from the
beginning of the separate graphics file, plus the length.

Jim,

Well, that's one box I won't be buying then!  Running NTFS 4K is generally
accepted as the optimum cluster size - so if a UNIX box is forcing 512K
clusters - well, (polite) words escape me!

But what you say sounds slightly contradictory - moving to individual JPEGs
made the size less?  Are you actually storing images as individual files or
in the database?

Whichever, it's clearly important to understand the implications of your
choice.

David

Quote:> I would have thought so myself. Our network has a Netgear ND520 20M
network
> attached storage 'server'. I changed from storing in blobs to individual
5 -
> 15K jpegs and the disk space went way down. It turns out that the cluster
> size on this server is 512K! Every 5K jpeg takes up a half meg of storage
> space on the disk. What a waste.

> Jim Margarit

I originally had the jpgs in a blob and the blob file had grown fairly
large. To cut down on the size, I deleted a bunch of jpegs from the blob and
the blobfile didn't shrink (I'm using DBISAM, which doesn't ever shrink blob
files). I was also worried about a blob corruption causing the loss of all
of the pictures so I went to individual files. There were over a thousand
pictures in the blob and it was 34M. When I converted the blobs to
individual files, the disk space used went up to 880M for the 1000+ files.
So now I don't know which direction to go. Probably just set up a new
server. The ND520 is slower than our old 433 celeron server anyway.

Jim Margarit

Hello People!

I get mad on a problem, that seems to be simple.
I created a table with a graphic-field and tried to load it into MS
Access. But MS Access didnt accept the saved bitmaps. Then I saved the
table in DBase/ Paradox-form, I changed the field-type from Graphic to
Paradox-Ole/DBase-Ole. Nothing works - MS Access is accepting the table
but doesnt display the pictures.
Can anyone help me?

Best regards!
Alex

Do you really want to save the binary bitmaps in the database?  Surely
better to save just pointers to the files (perhaps as URLs) in the database?
Ends up being a lot smaller!

(OK, so this may not suit you...)

Quote:> Hello People!

> I get mad on a problem, that seems to be simple.
> I created a table with a graphic-field and tried to load it into MS
> Access. But MS Access didnt accept the saved bitmaps. Then I saved the
> table in DBase/ Paradox-form, I changed the field-type from Graphic to
> Paradox-Ole/DBase-Ole. Nothing works - MS Access is accepting the table
> but doesnt display the pictures.
> Can anyone help me?

> Best regards!
> Alex

What version of Delphi?  of Access?  of the BDE?  Are you using ADO?  More
info, please.  Post your code that loads and displays the blob fields.

Thanks for that.

When I tried this (some time ago) the actual image had been stored, which I
hadn't been impressed with.  Ever since then I've stored images externally
as .JPG files and documents separately as .HTM files, so that not only is
the database made smaller and perhaps more robust, but the documents have a
useful existance on their own, and can be displayed, searched etc.

David

Quote:> David,

> In Access, as well as a few other DB's that I am aware of, the graphic is
not
> stored in the database itself, but rather in a separate file which is
simply a
> sequential byte stream of graphic after graphic.  The contents of the
graphics
> field in the database record itself contain the relative byte offset from
the
> beginning of the separate graphics file, plus the length.