|Index > Scribe > CSV import behavior|
|Author/Date||CSV import behavior|
|Another issue with CSV address book imports; during recent attempts at running the import tool I noticed that only the first few lines of the CSV file were imported into the contacts list. Reopening the CSV file afterward revealed that most of the data had been erased from it. This did not happen when the file was first tagged as 'read only' prior to import. Is this behavior normal?
Another request for the import utility; would it be possible to set up a user defined import map which could be stored as the default for future imports? Sure would beat manually selecting fields each time you do an import. An option to append an import to current listings or to replace them would be good too.
By the way, this is a great little program. Certainly beats Outlook in size and speed. Keep up the good work!
|Csv truncation: This is just a bug.
Remember field map: It should be too hard to remember the mappings, but do you want to read and write the mapping to a file or just remember it for next time?
Append or merge import: This could be problematical because there is typically no UID in the import data, and so it would be matching input against existing data using names and thats always a risky way of doing it. I'm just not sure it'd work that well.
|Remember field map: Storing the field map in a file would be useful for multiple future imports; I'm currently updating the address book by importing an exported file from Palm Desktop.
Append or merge import: Because I'm doing imports from a Palm database I'd like to replace the current content each time an import is done (can be done with other automation tricks but would be a lot cleaner if the option to 'replace current contact list' was part of scribe).
|Both the "append / merge" and load/save the field mapping will be in the next release.
|about that CSV import/export ... another problem is with "comma seperated values" as exporter in MS address book tells you, but in reality you get "semicolon seperated values" (at least i did) ... anyway ... quick fix around this would be to check either are there commas or semicolons in the first line of that CSV, and then work from there on accordingly ... that shouldn't be so hard to implement fReT? ;)
|Likewise you could open the file in a text editor and do a global search/replace to change all the semi-colons to commas. Adding that functionality into Scribe just to support a BROKEN export in some other program seems a little excessive to me, I want to keep the software small and simple, not cluttered with lots of little features or workarounds.|