"Don" wrote in message
ups.com...
Hi,

My boss asked me to build a database of embedded images of houses. I
tried to put them all in one table then quickly realized that I would
exceed the size limitation of the database. I suggested links but he
wants embedded images.

So, I created a new database and table for each house and linked those
tables to a main database with a form for photo entries. However, I
would like the user to open the form and be prompted to select which
table of photos he or she would like to edit or add to using the one
form.

If you are storing the images in OLE objects, using the BLOB method
described in the referenced example may save you enough disk space to store
the pictures in the database. Separate tables for each house/picture is a
difficult way to "make them fit" and will come back to plague you as you
need to enhance/modify the DB.

The sample imaging databases at http://accdevel.tripod.com illustrate three
approaches to handling images in Access, and the download includes an
article discussing considerations in choosing an approach. Two of the
approaches do not use OLE Objects and, thus, avoid the database bloat, and
some other problems, associated with images in OLE Objects.

If you are printing the images in reports, to avoid memory leakage, you
should also see MVP Stephen Lebans' http://www.lebans.com/printfailures.htm.
PrintFailure.zip is an Access97 MDB containing a report that fails during
the Access formatting process prior to being spooled to the Printer Driver.
This MDB also contains code showing how to convert the contents of the Image
control to a Bitmap file prior to printing. This helps alleviate the "Out of
Memory" error that can popup when printing image intensive reports.

Larry Linson
Microsoft Access MVP