How do I merge images into a word Doc from an access Query 1

[butcher]

Is it possible to have an image in an Access table display in a Word document using Mail merge. All attempts so far return the field but not the image. A report works well, however, using Word will allow the user to size and place the image to suit their requirements. Outputting to Word results in a RTF file - no images. All this is happening in Office ver97.

 

[matchmaker]

I have been dealing with this issue and this is how I have dealt with it.

Step One Get the path and file name of your graphics in the right format:

First I have a naming convention and a specific location for my jpeg files. I store the picture file name and location in my query and base the file name on a unique ID. For my purposes I use c:\pictures for storing my photos, however, when including a path you must use double slashes, not single, ie "c:\\picture\\filename.jpg"

Pass this field to your merge document instead of the object.

Step two set your merge document up to accept the filename into a field:

In your merge document chose Insert | Field and select Links/References then INCLUDEPICTURE then finish the command as follows
[INCLUDEPICTURE " " \c jpegim32]leave off the brackets

Click OK. This should give you a blank object. Click on it and press shift F9. This will reveal the code for this field. Insert the merge field with your file location between the double quotes.

When you do your mail merge this will send all the information you need to display the photo. The only drawback is you have to update the link to this object. Goto Edit | Links Update now.

As I said I have been working with this issue and this is as far as I have gotten.

I am still trying to find a better way to get the file name of the object. I would like to directly access the file name from the object itself, but have not figured that out yet.

Also, I am trying to get the merged document to automatically update the object, but have not figured that out either.

I hope this helps. If you have any thoughts about these other issues I would appreciate the input. Please let me know if this works for you.

 

[butcher]

matchmaker
The imperative to work in Word has eased for now.
This project is for wide distribution to agents and the client now wants more control over background&layout so keeping it all in Access seems safer for now (whew!)

My Brief:
A three section report on a stock certificate background:
TOP - Agent's logo/letterhead img - ONE per project
MID - Employer's logo/letterhead img- ONE per Agent
END - Trainee Name & accreditation txt - MANY per Employer
Background also uses accreditation Logo!

other issues:
-users have many different logo formats BMP WMF Jpeg etc
-lowest common denominator of User ability to deal with image formats.
-using FilePaths was too much for enduser and...
-getting images to 'appear' in access... well!
-seems easier to have user paste their image into ImageFrame - it 'appears' all the time.

I now have the user paste the image into the Table Field after copying from the 'associated program' in explorer. It works well but it obviously will not help if you need to keep a link to the image.

I use a table to store user's preferences for imgZoom Height Width and Left; all these are then passed to the report through the Detail Format Procedure at run time. I am still developing the interface form for recording placement options.

I may yet need the Word option so your assistance with this is greatly appreciated.
Have YOU tried to do your project entirely within an access report? It lacks certain finesse, but in the past i've used three or four Levels of Headings [as single field related tables] and two or three Body text fields [lowest level table]. These may be formatted as required with some success. You get a report something like Heading Levels in Word but no detailed formatting of the body of text.

You might hang all this text off the table holding your image, then report on a query that strings it all together. Make your report Fields [textboxes] .015cm high and use their CanGrow Properties to reduce white space when a HeadLevel or BodyTxt is unused. Let me know if you try to go this way.


Thanks for your response
butcher