Form won't accept any more pictures

[Guest]

I have 1637 records in my database already and only less than half way
through my collection. Each record has a photo which I have pasted into the
'photo' field box (reduced size and res to fix box). It will no longer accept
any more pictures but will accept a new record with only text. On reading
this forum I realise I should have saved each picture in a separate directory
and 'linked' the field by File/Browse etc etc. Was this the actual problem ?
and if so do I now have to copy and paste every OLE object and save it in a
separate directory one by one and then File/Browse to re-link them ? My
database is already 2Gb+ and is Access 2003. I could be here for years
copying 1637 photos just to get it to work now. Hope someone can help.

Thanks

 

[Douglas J. Steele]

2 Gb is the maximum size an MDB file can be.

To convert your OLE objects back to files, take a look at
http://www.lebans.com/oletodisk.htm

 

[edward]

I have 1637 records in my database already and only less than half way
through my collection. Each record has a photo

With this many records, I have to ask why you are entering so many
photos. If it's a personnel system and you need to store photos of
employees, that's reasoanble -- except that a company with 3,000
employees would have far more than a home-grown Access database for
personnel.

OTOH, if your primary purpose is cataloging the photos themselves,
there are many packages out there which do a far better job than you
have a chance of doing in a single lifetime. I use Photoshop Elements
-- which in fact uses the Jet database engine, meaning that when I need
to fix up the PSE catalog, I can open it in Access and alter it. (This
isn't normal operation, but has occurred when I needed to rename the
disk on which my images are stored, without actually moving them.)

The current version of Access is just outright poor at dealing with
images in the database. It simply does not have the concept of a linked
image -- you can store an image file path in a text field, but then you
have to code the actual display. (PSE works because it stores the path
in the database but it's only using Jet, not Access, and so indeed it
does the image display itself.) I have a very small Access database to
catalog images of my wife's art work along with information about
framing and shows -- too much to cram into PSE. But displaying the
linked images in forms using only Access requires pretty stupid tricks,
and it's slow. My DB has only about 40 records, and it's already too
clumsy and I'm not getting the benefit I wanted from it.

Perhaps the next version of Access will implement a "linked image" data
type. I haven't looked at the feature list.

Edward

 

[Guest]

Hi Edward
this is a private tennis collection over 25 plus years I am now cataloguing
with photos (small ones), I just happened to have Access and know a little
about the program so thought this would be the best one to use. I had no idea
there was limitations on the MDB size or I would have looked for something
else before starting out. Thanks for the program mentioned, I will look into
that and others if available.

Tom

 

[Guest]

Hi Douglas
I have looked at this site and downloaded the A2K+ zip file, will see how I
go, thanks. I have mentioned in the other reply from Edward why I have such a
large database and will follow his advice also. Great forum this, wish I had
found this 3 weeks ago when it all happened.

Tom

 

[Larry Linson]

this is a private tennis collection over 25 plus years I am now
cataloguing
with photos (small ones), I just happened to have Access and know a little
about the program so thought this would be the best one to use. I had no
idea
there was limitations on the MDB size or I would have looked for something
else before starting out. Thanks for the program mentioned, I will look
into
that and others if available.

Edward has a very authoritative tone, but unfortunately, Edward apparently
is not aware of some different ways to use Access for handling images. 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. And, not covered
in that article are temporarily linking external graphics file to unbound
OLE frames and using hyperlinks, so there are at least two additional
methods.

I agree that there are some good software packages, but if you have
requirements that those packages do not satisfy, you can, indeed, use Access
to manage, catalog, and handle your image collection.

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

 

[Edward Reid]

Larry,

There's no doubt that your techniques and generous offerings (and
Stephen Lebans') on this topic are invaluable to those who must include
images in Access databases. I in fact used some of these when I built
the small DB which I mentioned.

However, I stand by my statement: Access is poor (unqualified) at
dealing with images. Your methods -- in fact, the very fact that your
methods are even needed -- prove my point. If Access were to gain an
"image" type for table fields, with related methods, then all your
techniques, and all the tricks for printing, would go into the bin
marked "for previous versions only". Any half-decent photo organizer
does all the needed image handling with no add-ins and no such problems
to solve. (Where I'd call Picasa half-decent, and PSE decent.) Yet a
photo organizer will also have ten times more image-related
capabilities, especially in the areas of dealing with high resolution
photos, multiple resolutions, printing, organizing image-related
outputs, etc.

When I built my DB, I looked for techniques for dealing with images. I
used what I found, including either yours or some very like yours. (It
was a year ago and I forget the details of the sources.) Just getting
an image to be linked by a table field is clumsy. I still had to play
around with events to get images to display on forms consistently. I
couldn't print a ten-page report with three images per page, and ended
up doing more implementation to print single pages. Displaying the
image in a form remains ssslllooowww.

Can one get around these problems? Yes, you've shown that.

Is it easy? No, even with your contributions and Stephen's, it's
seriously time-consuming.

Is it a good way to handle images? No, the most basic image organizers
are much better at image-specific tasks.

Obviously there are a great many things which Access can do which no
image organizer can touch. In fact, this includes most of what Access
can do -- image organizers are a very specific niche product. When you
need to add images to an application which uses these capabilities,
then your contributions are invaluable, and I very much appreciate
them, as I'm sure do many others.

As an example, the OP mentioned a "private tennis collection". If his
focus is on statistics of tennis matches, needing reports and numerical
summaries, with photos just used as an adjunct to much more greatly
detailed numerical and verbal descriptions, then he obviously needs
Access. But if his main focus is on the photographs, with the
additional information being related to the photos (for example, when,
where, name of match, name of players), then Photoshop Elements (or
other good photo organizer) will be much easier for him to use and
offer him far more capabilities. Based on his description of what he
was doing, I felt there was a very good chance that he fell into the
latter category. This is a decision that only he can make.

Edward