Exporting street addresses correctly?

[Tom G.]

How can I get Outlook 2003 to export street addresses correctly so that
multiple lines are put into separate fields?

If I have an address like this:

Building 843-B
1234 Somewhere Street
Somewhere, CA, 92123

it exports as:

BusinessStreet: Building 843-B||1234 Somewhere Street
BusinessCity: Somewhere
BusinessState: CA
BusinessZIP: 92123

It appears that two <return> characters are inserted on export and both
lines show up in one single field. They really should stay separate as
BusinessStreet & BusinessStreet2.

Suggestions? I have a fair number of folders that I need to export for some
direct mailings. Those paragraphs play hell with most mailing software.

 

[Russ Valentine [MVP-Outlook]]

How are you exporting?
A mail merge would provide the most control over field placement.

 

[Tom G.]

How are you exporting?
A mail merge would provide the most control over field placement.

Direct from Outlook. File / Import/Export. Are you saying that Word knows
how multi-line street addresses should be parsed? Can I create an exported
data file doing this? The ulimtate destination for these names/addresses is
a direct mail house that only deals with CSV, DBF, XLS and tab-delimited
files.

 

[Karl Timmermans]

At the risk of interjection here on Russ' response-

Yes MS word does understand the structure of the "street address". In short
it correctly handles the <CR><LF> characters that any "current mailing
house" should also do. When the address field is "exported" (format is
irrelevant for this discussion) - it is exported as a single field with the
correct line break characters for a target that can deal with a single field
that has multiple lines. Even in Excel these will appear as a single line
unless you format the cell correctly, same in MS Access etc etc (you just
need to know what to do)

In the case of your direct mail house - some things you may want to check

#1 - Do they support "multi-line" fields for any of the fields (if they do -
you have should have absolutely nothing to worry about) OR......
#2 - Are they what I would call "old school" and expect a separate line for
every address line (which to be honest was a standard practice back in the
70's+ when I even architected some applications like that since it made
sense at the time in the mainframe/mini world)

If your mailing house are of the #2 category, then I'd suspect that they
have a finite limit of address lines (typically 3 or 4) that they will
accept and if they are any good at what they do - take the steps to delete
empty lines <within> a multi-line/multi-field "street address". You will
have to ask what happens for the address lines that exceed whatever the
limit is and what do they do when they encounter <CR> <LF> characters within
a single field. Outlook will allow you to create a very large "multi-line"
street address if one was so inclined (in fact Outlook allows a user to do a
number of things that don't make any sense at all in a conventional database
envirnoment under the auspices of being "user-friendly" when you try to
migrate Outlook data outside of Outlook - another issue for another day)

In short - in this case - may I respectfully suggest that neither Outlook or
your "mailing house" are "incorrect" in how items are treated - just may not
be talking the "same language" so one could ask - who needs to adapt to whom
in the grand scheme of things? (for what it's worth - in the next 2-3 weeks
we hope to have a comprehensive "ContactGenie Exporter" in beta that among
many other things deals with the issue of splitting address lines to a
user-defined number of lines for those locations that "have to have"
separate address line fields) .

Karl

__________________________________________
Karl Timmermans - The Claxton Group
ContactGenie - Importer 1.3 / DataPorter 2.0
"Power contact importers for MS Outlook '2000/2003"
http://www.contactgenie.com

 

[Russ Valentine [MVP-Outlook]]

I am saying that your question is too vague to permit an accurate answer.
Without knowing what type of document or file you want to create it is
impossible to give you an accurate answer.
Fortunately, Karl was kind enough to cover the entire waterfront for you.
That requires far more expertise than I have.

 

[Tom G.]

Yes MS word does understand the structure of the "street address". In
short it correctly handles the <CR><LF> characters that any "current
mailing house" should also do. When the address field is "exported"
(format is irrelevant for this discussion) - it is exported as a
single field with the correct line break characters for a target that
can deal with a single field that has multiple lines. Even in Excel
these will appear as a single line unless you format the cell
correctly, same in MS Access etc etc (you just need to know what to
do)

Sorry for the delay in replying. I've been on deadline at work. :-(

The two mailing houses I deal with charge an extra $50 to handle multi-
line street addresses. The other problem is that people in our office
enter addresses inconsistently.

In short - in this case - may I respectfully suggest that neither
Outlook or your "mailing house" are "incorrect" in how items are
treated - just may not be talking the "same language" so one could ask
- who needs to adapt to whom in the grand scheme of things?

Since we end up doing things across a number of apps, it would be nice if
the export were descretely fielded without the multiline stuff. I've
worked with a number of different contact manager apps and none that I
can recall store the street in multiline format. Most use the "old
school" addr1, addr2, addr3, city, state, postal code format.

(for what
it's worth - in the next 2-3 weeks we hope to have a comprehensive
"ContactGenie Exporter" in beta that among many other things deals
with the issue of splitting address lines to a user-defined number of
lines for those locations that "have to have" separate address line
fields) .

Yeah, I've played with CG a little. Seems fairly powerful but the
interface is a bit confusing. I had hoped the release version would do
the splitting but since it wouldn't, I stopped mucking with it. I'll
watch for the release of the new version. I was also interested in
seeing if it would work as a web to public folder synch tool but that's a
whole different story.

Thanks for the info.