How many times of you seen someone ask (or have even asked yourself) – Why are there so blank rows when I import my Excel file into Outlook (or even a CSV file created via Excel)?

There are many things you don’t have to think about when working strictly within the confines of a one program. However, when the data contained in one program has to be used in another program, the integrity of the data becomes important.

People new to import/export frequently pose a question to an Outlook group asking “How do I import from program “x”? The typical (and correct) response is “Look to see what formats does “program X” export to and select that”

For some reason, when Outlook is involved, far too many people seem to think that anything involving Outlook is an Outlook issue. What really needs to be understood is that the actual importing and exporting from any program is a defined process. The import/export functionality in Outlook has not changed since Outlook ‘2000 (or possibly Outlook ‘97) and deals with very specific kinds of data.

QuickPort v1.0.3 and DataPort v3.0.3 have been released to address an issue causing an Outlook termination error when importing into a contact folder using a custom form. As the documentation states for these programs, Microsoft Outlook (or more specifically the Outlook Object Model) is not used to perform any import/export activity. However, when Outlook is installed, the Outlook.exe is the component which returns the custom form information.

A complaint seen frequently is that when street address fields are exported from Outlook, the field is either not exported correctly and/or the field contains strange characters.

The most important thing to remember regarding street addresses is that the street address is stored as a single field within Outlook which is also the way it is exported. When exporting the street address via the Outlook export wizard to either Excel or Access, the entire field may not be visible giving the appearance of missing information. The reality is that the cell (in Excel) or field (in Access) simply needs to be expanded to show all the information.

There are two sets of field names used by Outlook for standard fields – internal names and Display Names (used by the Field Chooser during custom form design and shown in the All Fields List when displaying detailed contact information).

The Display Names are based on the Microsoft Office language setting in use and change accordingly whereas the internal names always remain consistent. When information is exported from Outlook via the Outlook export wizard, the internal field names are used.

Using the Outlook import/export wizard is not an option when you want to import/export:

1. any user-defined fields (standard message class)
2. custom fields contained in a custom form
3. an Exchange public folder
4. a delegate Exchange folder
5. any standard field that does not appear in the Outlook import/export field map

The Outlook import/export wizard only creates new contacts using the standard contact form (MessageClass = <IPM.Contact>) regardless of what the default is for the form

Importing from an Excel file is very common activity. There is likely a good chance that if you are reading this that you are currently investigating a problem that you are having or have had one in the past. One Excel feature that probably generates the most questions (and problems) is “Named Ranges” which include the following:

• When I try to import it keeps asking me for a “named range”

The terms <user-defined fields> and <custom fields> refer the same thing – fields defined by a user that apply to a contact in addition to the standard Outlook fields.

However, for ease of reference, the term <custom fields> is used for those user-defined fields that are defined as part of a custom form.

There are some essential differences between <custom fields> defined in a custom form and <user-defined fields> used with contact items using the standard Outlook form (messageclass – <IPM.Contact>) some of which are:

An area that seems to confuse many people are user-defined fields in terms of where and when these get created. This article specifically addresses the topic from the standpoint of user-defined fields used when no custom form is in use (when the default MessageClass is <IPM.Contact>.

There are two separate and distinct (but related) groups of user-defined fields for Outlook contact items.

• <User-defined fields in folder>
• <User-defined fields in this item>

Every Outlook item is created with a <form> which translates to the message class name that is assigned to it. To state this another way, <out of the box>, a default form is used when a contact is created. In the case of contacts, this form is assigned the message class of <IPM.Contact>. It is the design of the form in use that dictates how information will be entered for a contact.