But no one is talking about Access here - only Outlook.
--
Milly Staples [MVP - Outlook]
Post all replies to the group to keep the discussion intact.
ALWAYS post your Outlook version.
How to ask a question:
http://support.microsoft.com/KB/555375
After furious head scratching, Stewart Berman asked:
| The current version of Office seems to handle this. Prior versions
| -- Access 2002 and prior (perhaps 2003 but I don't have time to test
| it) -- treated the embedded carriage return / line feed as an end of
| record leading to some interesting results. It only took MS twelve
| versions (possibly eleven if 2003 can handle it) of Office to get
| Access to import a "properly constructed" CSV file containing
| <multi-line> fields without having a nervous breakdown.
|
| The xls format is a bit safer for moving between Office products
| unless you can be sure the user is on the latest version of Office.
|
|
|| If you're suggesting that a "properly constructed" CSV file
|| containing <multi-line> fields messes things up - would beg to
|| differ. The only time that would mess anything up is if the program
|| reading the CSV file is not designed to deal with this very common
|| occurance (the operative words in this sentence are "properly
|| constructed"). There are, however, many programs that do not
|| properly construct and/or are not able to read a CSV file with
|| <multi-line> fields but Microsoft products are not among them (nor
|| are ours for that matter).
||
|| Easy enough to prove - simply save an Excel worksheet that contains
|| <multi-line> cells (such as street address) as a CSV file and then
|| open it up again in Excel (or import it into Outlook). You will find
|| the exact same data with each <multi-line> field in a single cell -
|| exactly as contained in the original worksheet. Same thing for
|| exporting any contact with a multi-line address from Outlook and
|| opening it up in Excel.
||
|| Karl
|| ______________________________________________________
|| Karl Timmermans - The Claxton Group
|| ContactGenie - Importer/DataPorter/Exporter/Toolkit
|| "Contact import/export/data management tools for Outlook '2000/2007"
||
http://www.contactgenie.com
||
|| ||| Outlook exports contain fields with embedded carriage returns.
||| They will really mess up a CSV file.
||| An Excel file export will contain the field with embedded carriage
||| returns in a single cell.
|||
|||
|||| Would just like to add a few things for the sake of
|||| "perspective/clarity".....
||||
|||| #1 - When a response states that "import/export" is never the
|||| right way to do something" - it inevitably always relates to a
|||| scenario of moving information from one Outlook configuration to
|||| another (either implied or explicitly stated). It's also a
|||| recommendation I wholeheartedly agree with but the operative words
|||| are "moving from one Outlook config to another" - it
|||| is not one you will see when the requirement is to move info into
|||| or out of
|||| Outlook for use by another program.
||||
|||| #2 - The Outlook import/export wizard works perfectly and exactly
|||| as advertised (for the intended purpose). Would be the only thing
|||| you need (as
|||| qualified below) to save your data for use by another email client
|||| or program IF (and I stress the word <IF>) that other program does
|||| not directly
|||| provide the capability to retrieve the information from Outlook
|||| itself. One
|||| of the primary mistakes people make when using the Outlook
|||| import/export wizard is to let it "auto-process" (i.e. auto-map)
|||| which invariably causes problems in many cases. Not because the
|||| wizard doesn't work but because the
|||| person did not ensure that the <correct> desired fields were
|||| included (Outlook remembers the fields used in the last
|||| import/export function for the file type selected).
||||
|||| #3 - If your requirement only involves standard Outlook data that
|||| is included in the Outlook import/export field map - no need for
|||| anything else.
|||| On the other hand, if the requirement(s) fall(s) into one or more
|||| of the following - a 3rd party solution is required (whether ours
|||| or any one elses)
|||| a) import/export any Outlook standard field not found in
|||| the Outlook import/export field map
|||| b) import/export any user-defined fields whether as part
|||| of a custom form or as part of the "User-defined fields in folder"
|||| group c) import data to "update" existing Outlook
|||| contacts d) run on an automated or repetitive basis
|||| e) want to import/export from/to Exchange public folders
|||| f) want to import custom "FileAs" values
|||| ............or any number of other
|||| requirements....
||||
|||| Given that we sell import/export/field management products for
|||| Outlook, certainly would be to our advantage if the statement
|||| "using the Outlook import/export has/creates nothing but problems"
|||| was correct but <it's not> -
|||| it works just fine. Issues will occur if the data is not valid, if
|||| the import/export settings are not correct or wanting to do
|||| something that it was not intended to do - only need to review the
|||| myriad of posts to the newsgroups related to this subject to
|||| confirm that).
||||
|||| There are, however, 3 things that, that I suggest people avoid/do
|||| when importing/exporting Outlook info for any reason to minimize
|||| potential problems:
||||
|||| #1 - avoid PST to PST import/export - have yet to see a logical
|||| reason for PST2PST
|||| #2 - when importing data which is in Excel format - save the data
|||| as a CSV file and import that file instead (but not because of
|||| missing email addresses - the only reason that would happen is
|||| because something was not set correctly)
|||| #3 - when exporting and the final desired file format is Excel -
|||| save it as
|||| a CSV file, open the CSV file in Excel and then re-save it in the
|||| desired Excel format
||||
|||| In short - you have everything you need in Outlook to maintain
|||| complete freedom to move to/from any client or view your data any
|||| way you wish at any
|||| point in time.
||||
|||| Karl
|||| ______________________________________________________
|||| Karl Timmermans - The Claxton Group
|||| ContactGenie - Importer/DataPorter/Exporter/Toolkit
|||| "Contact import/export/data management tools for Outlook
|||| '2000/2007"
http://www.contactgenie.com
||||
||||
||||
||||
||||
||||| Thanks a million Brian. I can now use the To: button in the new
||||| message window to access my contacts.
|||||
||||| It's too bad that one must use the .pst to ensure functionality.
||||| I do not want to be tied to MS or MS Outlook. I use it for now,
||||| but who knows what I'll use in the future, and I want to make
||||| sure I have the flexibility to use my contacts data file to
||||| import somewhere else in the future. I also want a data file to
||||| simply browse or manipulate in other ways. I find often with MS
||||| that things are too good, too robust, too capable for something
||||| simply like having a data file of contacts that can integrate
||||| with email while also remaining independent, or in the format of
||||| a cross platform third party. I understand that every company to
||||| some degree designs its software and hardware to be proprietary
||||| to encourage customers to stay with that company. But more and
||||| more other companies are beginning to break that mold as more
||||| customer demand flexibility. It seems MS is behind on this front
||||| and doesn't really intend to make up ground here. This will
||||| likely encourage me to move away from them over the long run. Oh
||||| well.
|||||
||||| Thank you again for your help. This is exactly what I needed to
||||| know to get through this period of my life juggling several
||||| computers.
