Insert of Pictures to a Form

[Crispy]

I am making up a Record and ALbum Database and want to add pictures of the
covers.

When I first did it with 1200 albums and CD's the database grew to close on
2Gb very quickly although the pictures I am inserting are a max of 30K each!
Also, the pics are LINKED and NOT embedded. SO I am surprised it gets
sooooooo big!

How can I ensure I can add the pictures but also keep the database to a
handlable size? In other words still have reasonable looking cover pictures
but a database that can continue to be added to?

Thanks in advance.

 

[Kelvin]

When you add pictures into Access, Access keeps track of the data for the
picture and other overhead information. This is what causes you database to
get huge. This term for a database getting huge because of overhead
information is called bloating. Anytime you use OLE objects, this bloating
occurs. The best approach to dealing with pictures is to store the pictures
as their original file (JPG, GIF, BMP, etc.) in a subdirectory, then use
code to load this picture into a picture object on a form. It is a little
slower than storeing the picture in the database, but the space savings is
amazing. You could also use any size image, it will just get slower the
larger the image is.

Linking an OLE object will still cause bloating. Linked OLE objects are not
really linked. It still stores as much information as if it were embedded.
The only difference is that it will update itself (if needed) from the
source when it is called.

Kelvin

 

[Crispy]

And how do I find out what the code is, and where do I put it?

Thnaks

 

[Kelvin]

The code is pretty simple. On your form just create an image object. Set
the source for this object to nothing. The code would then be:

Me.NameOfImageObject.Picture = [txtFileName]

Where txtFileName is a text box that contains the full path and filename of
the actual image you want. this will change the source of the image which
is currently nothing to the image specified in your path. There are many
ways to specify the path. You can type it in, or create a directory
listing, or use windows' open command dialog.

Put the above code in the OnCurrent event of the form. That way it will
update for each record. If you will be entering the filepath and name then
add

Call Form_Current

to the AfterUpdate of the textbox where you will be entering the filename
and path.

Kelvin

 

[Crispy]

And I would have to do that for some 1200+ images?

The code is pretty simple. On your form just create an image object. Set
the source for this object to nothing. The code would then be:

Me.NameOfImageObject.Picture = [txtFileName]

Where txtFileName is a text box that contains the full path and filename of
the actual image you want. this will change the source of the image which
is currently nothing to the image specified in your path. There are many
ways to specify the path. You can type it in, or create a directory
listing, or use windows' open command dialog.

Put the above code in the OnCurrent event of the form. That way it will
update for each record. If you will be entering the filepath and name then
add

Call Form_Current

to the AfterUpdate of the textbox where you will be entering the filename
and path.

Kelvin

And how do I find out what the code is, and where do I put it?

Thnaks


database

savings

is are
not of
the

to

a

 

[Larry Linson]

And how do I find out what the
code is, and where do I put it?

Download the sample database from http://accdevel.tripod.com that
illustrates three approaches to handling images in Access. Feel free to use
any objects or code as a starting point. The download also includes an
article that explains the bloat you are experiencing.

Larry Linson

 

[Exponent]

When you add pictures into Access, Access keeps track of the data for the
picture and other overhead information. This is what causes you database to
get huge. This term for a database getting huge because of overhead
information is called bloating. Anytime you use OLE objects, this bloating
occurs.

This is not strictly accurate. Access can store any binary data (including images) in OLE Object fields
without any significant overhead compared to using the filesystem. It is the use of OLE Embedding and
OLE Linking that can cause an overhead when working with compressed images (especially jpeg - anything
from 5 to 100 *times* the size of the original file).
When storing images actually in tables avoid this and other potential drawbacks to OLE Embedding (& Linking)
by storing the raw binary binary data only. Otherwise work with external files and only store (or generate)
the path.

 

[Kelvin]

Yah. You could make it easier by using a standard naming convention. If
you name all the pictures to match the name of the album in the table or to
some other piece of info, you could have the program automatically generate
the full path and filename. For examle, if you have the Album1 by Group1
stored in a directory called Group1 with the filename Album1.jpg then you
could have Access automatically generate the path and filename
"\Group1\Album1.jpg". Since you already have most of your collection
finished, I would just do this for new albums and you can convert your old
data at a later date. Check out www.MVPS.org. I beleive there is a routine
there to write OLE images back out to an image file. You could have access
automatically create these images in the standard convention I mentioned,
then you won't have to reenter all the names.

Kelvin

And I would have to do that for some 1200+ images?

The code is pretty simple. On your form just create an image object. Set
the source for this object to nothing. The code would then be:

Me.NameOfImageObject.Picture = [txtFileName]

Where txtFileName is a text box that contains the full path and filename of
the actual image you want. this will change the source of the image which
is currently nothing to the image specified in your path. There are many
ways to specify the path. You can type it in, or create a directory
listing, or use windows' open command dialog.

Put the above code in the OnCurrent event of the form. That way it will
update for each record. If you will be entering the filepath and name then
add

Call Form_Current

to the AfterUpdate of the textbox where you will be entering the filename
and path.

Kelvin

And how do I find out what the code is, and where do I put it?

Thnaks


When you add pictures into Access, Access keeps track of the data

for
the

picture and other overhead information. This is what causes you database
to
get huge. This term for a database getting huge because of overhead
information is called bloating. Anytime you use OLE objects, this
bloating
occurs. The best approach to dealing with pictures is to store the
pictures
as their original file (JPG, GIF, BMP, etc.) in a subdirectory, then use
code to load this picture into a picture object on a form. It is a little
slower than storeing the picture in the database, but the space

savings

is
amazing. You could also use any size image, it will just get slower the
larger the image is.

Linking an OLE object will still cause bloating. Linked OLE objects are
not
really linked. It still stores as much information as if it were
embedded.
The only difference is that it will update itself (if needed) from the
source when it is called.

Kelvin

I am making up a Record and ALbum Database and want to add

pictures

of to