Importing contacts from third-party database

  • Thread starter Thread starter noel.whelan
  • Start date Start date
N

noel.whelan

I'm working on a project in which I've got a contacts database, in
which each contact can be identified with 1-to-n e-mail addresses,
phone numbers, companies, etc. I need to create a basic function to
export this data to a CSV that can be imported to Outlook (ideally with
one entry per contact, but which incldues each piece of information
identified with each contact).

I'm looking in the properties for an existing contact in Contact
Fields. It looks like these would essentially cover everything I'd want
to export for this purpose; but I notice a few potential issues. It
only lists three e-mail fields: E-mail, E-mail 2, E-mail 3, for
instance. If a contact were identified with 10 e-mail addresses in the
database, it'd be convenient to write the CSV to include fields like
E-mail 4, etc. I tested this and noticed it won't cause an error; but
it ignores the E-mail 4 field when imported (I would've thought this
field would perhaps be viewable in User-Defined Fields, inferring that
if it didn't exist in the defaults). Identically with Other Address or
Business Address fields: I created a CSV with fields like Other Address
2 (basing this on what looked to be the E-mail field naming
convention); but these were ignored I think during import.

I don't want the process to come off too involved to the user, with
defining custom fields or choosing existing ones into which these data
ought to be imported (if they don't want to); but I'm thinking that
this is essentially what'll need to be done in cases where the defaults
won't be enough. I'm basically just posting this in order to confirm
that; or if I'm wrong (I'm just basing this on what I've tried thus
far) I'd be interested to learn what else could be done.

Thanks for any input..
 
Outlook has no native import to custom fields, and you can't create new custom fields that act like email address fields. Your CSV export file should limit itself to the fields that a contact supports natively.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
 
Thank you. In view of that, I've thought of importing each contact once
per e-mail address (why bother identifying three with each if there's
four e-mails, for instance, thereby yielding two contacts). I'm
inclined not to do that, though. In this database, each contact can be
identified with 1-to-n companies, too, in which case they've
potentially got a dept. and pos./title identified with each company.
I'd come into this issue there, too, because there's no Company 2,
Business Address 2, Department 2, Job Title 2, etc. Identical with
phone numbers, where the contact could be identified with three cell
phones, two office phones, etc. In the database, there's no 1:1
cross-linking imposed between a contact's e-mail(s), business(es),
phone number(s), etc.; therefore I wouldn't know which e-mail(s) ought
to be exported with the 'instance' of the contact that includes company
1, for example.

I think what I'll probably do is just export what 'can be' imported
once for each contact (the first three e-mail addesses, 1 company,
etc.), and inform the user why this is.

I'd be interested in any further thoughts, too, of course. Thanks!
 
Barring writing customized code, the key thing that you need to do is
"normalize" the data you want/need to import and flatline all the
appropriate fields into one record. You don't mention what the database
source is but in the case of MS Access/MS SQL - this could be accomplished
with queries/views.

Outlook doesn't support a 1 to many relationship within contacts since it's
not a heirarchial db so you're restricted to the fields available "per
contact" (i.e. 1 Company Name, 3 email addressess, 17 (+/-) phone numbers, 3
addresses etc) or you can create a custom form adding whatever additional
user-defined (custom) fields are required. As Sue noted, Outlook doesn't
support importing of data to custom forms or any user-defined fields so you
would need to either write your own code or use a 3rd party product (i.e.
ContactGenie Importer & DataPorter both support custom forms/fields -
http://www.contactgenie.com/cg20features.htm).

Karl

PS - Must admit that your description of what the existing database does and
doesn't include/impose is a tad "confusing". Assumption being that whomever
is using the existing database would need to know what info belongs to what
(i.e. name to email address(es) to company(ies) etc) which in turn implies
that there is some critical structure in place which the parent application
of this database is using. Bascially what, if anything, makes a contact
unique within the original database or do the users look for available
contacts by company regardless of how many other instances there may be of
the same "name/person" within the database in which case you would be better
served by using something like BCM? (not really looking for a response to
this - just some food for thought).
_____________________________________________________________
ContactGenie - Importer 1.3 / DataPorter 2.0 / Exporter
"Power contact importers/exporters for MS Outlook '2000/2003"
http://www.contactgenie.com
 
Thanks for your input. In this database, I can browse either contacts
or companies (in which case a contact would 'come up' in each of the
companies identified with them, with their dept. and title
corresponding to that company); but when browsed as contacts, the
contact info will list each company identified with them.

I think what I've got in place works. I'm basically exporting the first
instance(s) of what can be imported directly to the existing Outlook
contact fields for each contact. I'll include a brief explanation that
if a contact is identified with two or three companies, for instance,
only the first will be included; or the first three e-mails, etc.,
which I think is fine.
 
Everything is relative since you didn't specifically mention (or I didn't
notice) whether your doing the import for a single or multiple persons (or
into an Exch public folder for general access). Depending on scenario - info
re: a contact vis-a-vis specific associated company may be of importance to
the person actually using the data as opposed to just taking the first "x"
fields (may make the data very difficult to use or outright useless for a
set of users but would also mean that you could identify which
<company/contact> info would be relevant to a specific user). Anyhow, just
something else to add to the mix of "possibilities" - assumption being that
there is a/are reason(s) for this data being captured / retained / accessed
the way it is in the prime application.

Karl

_____________________________________________________________
ContactGenie - Importer 1.3 / DataPorter 2.0 / Exporter
"Power contact importers/exporters for MS Outlook '2000/2003"
http://www.contactgenie.com
 
Back
Top