UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Mail Merge - Two Addressees, Office 2010    
 
   
wpla747
post Nov 17 2017, 12:29 PM
Post#1



Posts: 66
Joined: 2-January 12



I have a very large Contacts folder in Outlook with data that I use to create mailing labels. Some of the contacts have more than one name for a single address. I wish to print the label with each name on a separate line.

Example:

Mr. John Quincy Adams
Mr. Henry Clay
123 Main St
Newark, DE 12345-6789

I enter the above names in Outlook as follows.

Title: Mr.
First: John
Middle: Quincy
Last: Adams Mr. Henry Clay

The resulting label is formatted as follows:

Mr. John Quincy Adams Mr. Henry Clay

After the merge, I have to manually go through all the labels and move the second name down to the next line - a tedious process that requires repeating every time I create a new mail merge. I can get the labels to display the names on two lines by populating the Company field with the second name but then the Company of all the persons in the Contacts folder is propagated to the labels, which I do not want.

When inserting the merge fields, I use the Address Block for the whole address instead of inserting inserting each field (FirstName, MiddleName, LastName, HomeStreet, HomeStreet2, HomeCity, HomeST, HomePostalCode) in order to avoid the extra spaces when there is no middle name or the blank line when HomeStreet2 is blank.

Is there a way to create the label in the Example above without having to manually edit the merged file?

Wilfred Plá
Germantown, MD
Go to the top of the page
 
ranman256
post Dec 5 2017, 06:55 AM
Post#2



Posts: 788
Joined: 25-April 14



normally, youd remove the 2nd field from the merge template,
then re-run the merge.
Go to the top of the page
 
ranman256
post Dec 5 2017, 06:55 AM
Post#3



Posts: 788
Joined: 25-April 14



normally, youd remove the 2nd field from the merge template,
then re-run the merge.
Go to the top of the page
 
orange999
post Dec 5 2017, 07:50 AM
Post#4



Posts: 1,715
Joined: 10-February 08
From: Ottawa, Ont, Canada; West Palm Beach, FL


Bottom line is-- it depends on what your requirement is.
Seems you have 2 contacts, and should record each separately.

If you only want/need one contact from that input, then you need some logic to identify the data to be recorded and append the record.

It appears you need to confirm the requirement(analysis) , then adjust (design and test) the program accordingly.

--------------------
Good luck with your project!
Go to the top of the page
 
GroverParkGeorge
post Dec 5 2017, 08:40 AM
Post#5


UA Admin
Posts: 31,245
Joined: 20-June 02
From: Newcastle, WA


Unlike human brains, computers need clear-cut rules to work accurately. You are able to "eyeball" your contacts lists and decide how to handle each contact depending on context. Computers are not so flexible, at least not without some fairly sophisticated logic being developed and programmed. And even then, it may turn out to be the case that the rule is sufficiently complicated to make it nearly impossible to account for all possible cases.

So, here, the rule might initially appear to be fairly straightforward, given that you will ALWAYS have one or two contact names per address. But the way you apparently store these names is well outside the norm for addresses, and therefore can't be handled without custom functions you write for that purpose. In other words, by combining two people's names into a single field in the contact record, you're already stepping outside standard. Plus, you're using an existing field, LastName, for this purpose, which means that anything related to LastNames is always going to be a problem. Moreover, within that field, you are adopting an even more unusual convention, in which the last name of one person is combined with the full name of someone else.

In short, looking at this strategy would suggest maybe you've gone so far away from the standard methods of storing contact information that it might not be feasible to manipulate the information as you want, at least not without a pretty complex function. I'm not suggesting that you can't, but that it might not be worthwhile.

Instead, I'd suggest you adopt a strategy that takes advantages of the strengths of Outlook and avoids this kind of mind-bender.

But that begs another question, for which we ought to understand the answer before moving forward.

What does this unique strategy for storing names gain you now? How do you use this merged naming approach for multiple contacts at a company? Why does it exist in the first place?

Thanks for clarifying the situation.


--------------------
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    17th December 2017 - 10:21 PM