Question for all MVP's CC pictures in DB *842008

[J.Alladien]

Dear All,

I am working on my products catalog and I have 2 dtbases; one uses the OLE
method, the other one the "path to picture method"! (tot qty pics: abt
1000-1200)

I have to deliver my whole catalog in a PDF file to a printing-office in
order for them to print HARD COPIES for my clients!

In the db that uses the "path to picture method" ,I get the following
error when scrolling in my report-preview mode when I scroll past lets say
after the 280th page (from 310 total);pls note that all pics are loaded fine
till page 280!

"my DB doesn't support the format of the file F:\jetzza\1012.jpg or the
file is too large;try converting the file to bmp or Gif format"

This goes on till the last page, the code being used in the report is:

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
On Error GoTo Err_cmdClose_Click

'set the picture path
Me.ImgStock.Picture = pathname & "\" & Me.txtStockGraph

Exit_cmdClose_Click:
Exit Sub

Err_cmdClose_Click:
If Err.Number = 2220 Then 'can't find the file
Resume Next
Else
MsgBox Err.Description
Resume Exit_cmdClose_Click
End If

End Sub

When I try to convert my report to a PDF file ,it gets an error stopping
around page 280 ,if I try to convert it in bits lets say from pg 1-50 ,51-
-100 etc I get he same error!

My "OLE " db however has no problems ,works fine even better the then my
other DB .the above only applies to the reports ,Forms are no problem at all
in both databases!

Is there a solution to this problem? Am I the only one having this problem?
The problem is I think primarely when the pictures get loaded on the report!
Is there a code that has a solution to this problem!
Please help!

 

[Klatuu]

Storing images in your database is not a good idea. An mdb file is limited
to 2GB. It doesn't take too many images to blow that limit. Therefore, the
path to image is a much better solution.

The error is telling you what the problem is. Only .gif and .bmp formats
are supported in this context.

 

[J.Alladien]

OHHHH,

I wish somebody had told me this earlier, anyway I exported all the Ole
objects to Bitmap format and I tested it and I think it worked, I was able to
print them to a PDF file wihout errors this time ,but still have to check if
every picture is correct!

The next problem is however that some of the bitmap images show "DISTORTED"
in the forms,is this normal? If not do you have a possible solution to this
problem?
The pictures in the report however are OK!

Thanks a lot for the help!

 

[Wayne-I-M]

To follow on from Klatuu's answer - note that when you output to pdf
(depending on how you do it) sometimes the files "load" - then - "output".
So you could be trying to load all the pics into the DB to output it. As th
DB can only be 2gb this could make a problem.

Access is not really meant for this. Also note that when you output a jpeg
you lose some quality so if your pdf is important you could look at a print
design programme - which of which output by batching (the file is split into
segments and each segment is output one after another in "batches")

The basics are that a product catalog should not be made using access (it is
a relational database not a design package) and you need to desgin it in a
design application

sorry - I know it's not what you want to hear. Of course this is only my
opinon so you may get different advice from another person that would say its
fine

Good luck with your application

 

[Klatuu]

Sorry, I really don't have any suggestions on that for you.

 

[Wayne-I-M]

The next problem is however that some of the bitmap images show "DISTORTED"

in the forms,is this normal? If not do you have a possible solution to this
problem?
The pictures in the report however are OK!

In your report the OLE (maybe) zoomed - your form (maybe)streched

 

[J.Alladien]

Dear Wayne,

Yes that was the problem, I knew abt this, it's just that I am so tired
that I forgot all abt it, anyway I hope all my problems are solved now and I
thank you very much for the help and advise!

 

[Wayne-I-M]

Best advice (think most people will agree). Don't use access to create
printing material - it "will" alomost work but the results will be very poor.

Use adobe, corell, etc

Hear is one I did a while ago (I have made a few like this).
I am not recommending corell its just what I use most of some other
programmes will just as well

If you create your printed brochure in corell you can link the pictures
(instead of imbedding) until you output - PDF's are NOT meant to print (high
quality) you "need" a CMYK AI or CDR, etc file - both these will maintain the
quality of the original.

If you use the same picture as the base for your path to the access form
"and" your brochure page, don't need to change either (corell or access) if
you change your picture - it is common to change / improve pictures so
linking is always a good idea.

Making brochures does take a while but if you rush it you will lose sales -
so it worth learning to do it right.

 

[Larry Linson]

The error is telling you what the problem is. Only
.gif and .bmp formats are supported in this context.

Klatuu, several other graphic file formats are supported, if the graphics
filters are loaded. The graphics filters come with the Microsoft Office
product and with standalone Microsoft Word. They apparently are loaded, as
witness, the original poster's report working for many records.

This appears to be a memory-leakage problem that occurs in some versions of
32-bit Access. MVP Stephen Lebans has an example and an approach to
correcting the problem at his website http://www.lebans.com, in re: which
see the following taken from my "standard response" to image questions:

"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.

And, Stephen has an ActiveX control available that works in cases where the
graphics filters are not available -- and works better, I've heard, than the
OLE Object and OLE Controls."

Regards,

Larry Linson
Microsoft Office Access MVP

 

[Larry Linson]

Best advice (think most people will agree). Don't use access
to create printing material - it "will" alomost work but the results
will be very poor.

In the words of our good friend and ex-MVP Michael Kaplan, "I'd sooner slide
down a giant razor blade into a vat of iodine" than create a catalog using
one of the software packages you mention. I respectfully disagree... I
often use Access to create reports that will be printed... a properly-done
report, as the original poster described will be far easier and simpler to
create with Access, and can produce a high-quality master file for
reproduction.

I do not store images _in_ my Access databases, unless they are few and
there is compelling need (say, to display them on a continuous form view
Form), but the external file method, used with quality images, ZOOMed in
Image Controls, converted to bitmap, works very nicely.

Hmm. Maybe the original poster hasn't see a post with my "standard response"
on image-handling. OK, here it is, in full:

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.

And, Stephen has an ActiveX control available that works in cases where the
graphics filters are not available -- and works better, I've heard, than the
OLE Object and OLE Controls.

Please note that there are other approaches, e.g.,
Application.FollowHyperlink, but those, like OLE and Bound OLE Frames still
leave you "at the mercy of the imaging software registered for the
filetype").

Finally, Access 2007 has enhancements that, reputedly, eliminate the
database bloat long associated with OLE Objects and Bound OLE Frames. But,
it still leaves you relying on the software registered for the image type,
which may not be as "cooperative" as we'd like in creating our display. It
also has the capability of having a variable number of Attachments to a
Record, which may be helpful. But, as I have not done much with it yet, I
certainly wouldn't suggest you rush out and replace an earlier version --
until you have a copy incorporating, at least, the first Service Pack, which
has been out for some months now, or have the SP in hand and ready to apply
as soon as you install Access 2007.

Larry Linson
Microsoft Office Access 2007

 

[Fred]

I do this (reports/literature and forms) with jpg's with no problem. (Access
2003)

I just learned how to do this 6 months ago, so I can't tell you why it
worked and your didn't.

Fred

 

[Fred]

Wayne,

I'd have to agree with Larry. Once you've created / managed / updated the
content for catalogs in a database, and then created catalogs directly from
it, I would consider duplicating it via manual entry / editing in a graphics
program to be the equivalent of mowing a lawn with scissors. But the razor
blade / iodine analogy also sounds good and more exciting.

Sincerely,

Fred

 

[Tony Toews [MVP]]

Note that there are lots of folks who have yet to be recognized as
MVPs who are quite capable of answering your question.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/