Before you get too hard on Nokia - dealing with multiple contact folders
within Outlook "can be" a major challenge to say the least. In a perfect
world where everyone followed some very basic database rules and if Outlook
dealt with a lot of issues itself - importing and exporting would be one of
the simplest processes out there. I suspect that Microsoft knows the issues
very well and is likely one of the primary reasons they themselves do not
offer anything "beyond" the "absolute minimum basics nor will you see much
of anything outside of the "standard" from any published book on the subject
(and our library owns just about every major title available from virtually
every recognized Outlook expert). Don't let me mislead you - I love
Microsoft and respect the experts - but dealing with Outlook data (in or
out) has been an interesting exercise and virtually "none of exceptions" are
ever addressed by anyone.
Specifically - just some of the challenges (for Nokia or anyone else dealing
with "generic" solutions) :
#1 - If you use a custom form - the export process must handle custom fields
(easy enough to do on a custom basis if you know the exact field names for
the user properties as shown in virtually every book out there. Not that
easy on a "generic basis" - in fact many "undocumented features(?)" come to
the "forefront" that seem to be never discussed anywhere.
#2 - Outlook supports usage of multiple forms (custom or standard) within a
single contact folder
#3 - If an export process is going to take place - each folder should at
least follow the same structure - ergo if using a custom form in one -
should be used in all. Unfortunately there is no guarantee that this will be
the case. In fact, one can't even depend on a custom form with the "same
name" published to 2 different folders to be the same using the same
fields......
#4 - Side issues are field names and length of text fields (Outlook places
no (within quantifiable reasonable) limits on amount of data that can be
stored in a "text field (in database terms - that limit is 255 characters -
beyond that - a <text> field generally becomes a "memo" field to use MS
Access data type definitions). So on a phone/pda - the issue also becomes
one of capacity etc. (for point of interest - the Outlook export process
"truncates" any "text" field to 255 characters).
#5 - In order to achieve any kind of "acceptable" performance - a vendor
needs to use MAPI directly or via a 3rd party product. However, contacts
created in one version of Outlook (let's say Outlook '2000) which have been
upgraded via the various editions may (will?) not produce the same results
(in other words - returns errors for specific fields) making the use of MAPI
unusable which in turn causes performance issues when reverting back to
using Outlook directly. Unfortunately - the processes used by Microsoft to
circumvent these issues are "proprietary".
.................and the list goes on and on and on
Outlook was designed to allow the user absolute freedom from any convention.
It was certainly not designed with any thought related to how to deal with
the information "outside of Outlook". That freedom comes with a price and
the effort to coral that is "less then trivial". We have reviewed all kinds
of "examples" - free or otherwise showing code that will do this that or the
other thing. All works fine as long as one stays within the "accepted"
constraints - else becomes very, very easy to break. Should someone care for
a simple scenario - like updating an MS Access database with data from
Outlook - use the sample code you are provided when the Outlook text field
exceeds 255 characters and the MS Access field is defined as a text field.
It will either truncate the data or encounter a fatal error (just depends on
the code and error-trapping in place).
Moral of this message - there are reasons why getting information into and
out of Outlook is not the easiest thing in the world (which translates into
time which = $$$ relative to the number of times a "customer" or "potential
customer" requests a feature).
How have I come to this conclusion? Simple - in the last few years, we've
run across and continue to run across an endless series of exceptions used
by Outlook users which makes our generic products seem to be the cause of a
"problem" when in fact if some basic "constraints" - all would work
normally. Comes a point where limitations need to be applied which means
some users are just not going to be able to export the data in a way that
they want using the "freedom" of Outlook. Add a multi-lingual -
multi-regional "international" dimension to this and it gets even more
"interesting" (our next generation of products will be able to deal with
Outlook display names in some 5+ different languages along with variable
regional data settings).
In your specific example - a single folder using "categories" for separation
may be a much better overall solution as was suggested elsewhere.
Just passing this along as "food for thought" as to why what should appear
as "simplistic" may not available (or even do-able in some rare cases).
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