It seems to work if I have up to 3 fields:
"email","first name","last name"
However, the display name is just the email even though I imported
the first and last names. I would have expected it to make the
display name out of the first and last name like it does when you
type in a single address card. That's the first issue.
But if I have 4 fields:
"email","first name","last name","display name"
It seems to suck in all the items of all the subsequent records
as additional fields. It doesn't seem to stop at the end of the
first record which contains the field names. In other words, the
field mapping window shows:
Primary Email email (this is OK)
First Name first name (OK)
Last Name Last name (OK)
Display Name fullname (OK)
Nickname Paul (the 2nd item of the 2nd record)
Secondary Email Kinzelman (the 3rd item of the 2nd record)
Work Phone Paul Kinzelman (the 4th item of the 2nd record)
etc...
If I add a 5th field "blank" and put in a " " it does the same kind
of thing, just an additional field.
This sounds like it's a bug, should it be reported someplace else?
TIA!
Click on the Address Book button to open up the address book window,
then select View -> Show Name As, you can then select different options
there.
> But if I have 4 fields:
> "email","first name","last name","display name"
> It seems to suck in all the items of all the subsequent records
> as additional fields. It doesn't seem to stop at the end of the
> first record which contains the field names. In other words, the
> field mapping window shows:
Are you putting the subsequent records on new lines? i.e.
fi...@invalid.com,first1,last1,display1
sec...@invalid.com,first2,last2,display2
> This sounds like it's a bug, should it be reported someplace else?
If this doesn't fix your problem, we'd need to see an extract of an
actual file that exhibits the problem, and the best place would be here
in the first instance.
Standard8
couple of quick comments.
When you export as .csv file it exports VALUES.
Display name is a constucted/calculated field within the TB internal
database.(first+last name) - if the "display name" is shown in the
address card properties it will be exported as a value.
When you import a .csv file, values are imported.
ie. if the field is blank in the .csv file, no value is imported and
will not be recalculated when you import the book.
Perhaps this can be called a "bug" - ???
When you export as .csv file, it will export 36 fields per record.
The first record will show the Field Names within each record.
There are approximatelly 76 fields defined in the TB book header.
Only About 36 are actually used.
One that is not exported to .csv is "8E=PreferMailFormat" - this field
IS exported with LDIF exports.
There are probably others ?
Does this help any ?
regards:captjlddavis
captjlddavis - no, blank fields and import/export are not the problem
I don't think.
Mark - I think it's really an importing bug. I've experimented with
it, and am happy to continue to spend time if the results are important
to getting it fixed. I've got 30 years in the computer field (low
level device drivers) so I understand the opportunity that a
fortuitous finding of a bug provides.
Take the following .CSV file. Notice I've changed "Display Name"
to be "phone" to make sure there's no problem with a
constructed/calculated field (as the capt suggested) even
though the full name is labeled as 'phone'.
"email","first name","last name","phone"
"some...@somewhere.com","Arthur","Somebody","Arthur Somebody"
"some...@somewhere.com","Bobby","Somebodyelse","Bobby Somebodyelse"
Now import it as CSV, notice that the 2nd line gets slurped into
the mapping window. The column "Record data to import" shows:
email
first name
last name
phone
Arthur
Somebody
Arthur Somebody
It looks like it thought the first real data entry record was actually
the 2nd half of the first (field name) line. And it skipped the email
part of the 2nd line, perhaps it didn't want to allow a "@" in the name
of a field.
Now remove one of the fields so the file contains:
"email","last name","phone"
"some...@somewhere.com","Somebody","Arthur Somebody"
"some...@somewhere.com","Somebodyelse","Bobby Somebodyelse"
Now when you go to import, the Record data to import column properly shows:
email
last name
phone
And it looks like it imports properly to the proper fields (even
though I've got the display name importing into the phone field
although I could map it if I were not so lazy :-).
Bug?
I've just tried this out on the latest test version of Thunderbird and I
don't see this problem, though I'm also on Mac. I'd have thought we
would have had more complaints if this was a real problem as well.
One thought I have had, is have you checked the line endings in your
original .csv file? I'm pondering that they may be just <LF> rather than
<CR><LF> (which I have a feeling TB expects on Windows), and hence the
reason for merging the lines into one.
If you're editing with a windows editor then it would automatically
convert the line endings to <CR><LF> when you save it.
Standard8
When you imports from a .csv file, the field data is imported in the
order of the columns.
First Name = first column
Last Name = second column
Display Name = third column
Nickname = fourth column
Primary Email = fifth column
Secondary Email = sixth column
etc....
When you import from .csv file, the first screen will show two columns.
READ THE INFO AT THE TOP OF THIS SCREEN
This indicates IF the data is to be imported and where to place it
you can adjust Where (internal field) that data wil be placed in by
Moving the entry UP or Down to correspond to the correct data.
Otherwise I am lost as to what you are doing.
HTH
regards:captjlddavis
It will import based on column position - regardless of name or content.
It will populate the book in the default format ( position )
Great idea about the CRLF thing. I can't tell you how much
frustrating time I've lost chasing that problem. However,
I downloaded a hex dump program to be sure, and yes, the
problem file in this case does have <CR><LF> after each
line according to the hex dump. I created it with emacs.
Re: the capt
Yes, I understand about the stuff at the top of the screen
and the order of import. I didn't list the first column
that I saw in the window because that's standard. In my
example I listed only the second column.
I got around this problem in my application, but I'm continuing
to pursue it because I think there might be a bug here that
needs looking at.
All I was trying to do was to import an address list that I
prepared with emacs into Tbird. And I created those CSV files
to illustrate the problem. Try running them yourself (if you're
on Windows) and see what you get.
Again, what I saw if I had 4 (or 5 too) fields in the first line
was that TBird did not stop at the end of the first line
when it displayed a list of fields from the input file.
I had only 4 (or 5) fields on the line, but it thought there
were more (like 7 or 8). If I had only 3 fields on the first
line, then it properly stopped at the end of the first line
when determining how many fields were in the input file.
Paul,
Sorry that I can not be of any help, I have absolutely no idea what you
are doing or trying to do.
regards:captjlddavis
I guess I'm not explaining myself clearly. All I was trying to do
was to import into Tbird's address book, an email/name list file in
CSV format which I created with a text editor. And I ran across
something that I think is a bug so I wanted to report it.
Is there a better place where I should report this?
Or better yet, could somebody else take the example files I provided
in an earlier posting and try running them? Mark said he tried it, but
he's on a mac and we all know things work better on a mac. :-)
Tb address books are based on MORK db......enough said.
as a last idea, in you original .csv....
Duplicate the first entry.
eg:
"email","first name","last name","phone"
"email","first name","last name","phone"
"some...@somewhere.com","Arthur","Somebody","Arthur Somebody"
"some...@somewhere.com","Bobby","Somebodyelse","Bobby Somebody"
when you import, select the correct fieds in then - adjust position as
needed.
regards:captjlddavis
regards:captjlddavis
Re: Capt
It shouldn't be necessary to duplicate the line, but if that
solved the problem (and I don't think it would),
then Tbird is clearly broken and needs
attention by a developer. Having a working import facility
is important and the fact that Tbird didn't have a
working one until recently caused me not to move from
Eudora to Tbird until it worked.
And it can be worth the trouble if I have a lot of names.
In emacs, I can do all sorts of reformatting to get a list
of emails into a format that should be acceptable to the import.
My test case was just to illustrate the problem. When
debugging, the smaller a test case the better.
Is there a forum someplace where bugs should be posted?
I'm pretty convinced that this is a bug.
> Re: Capt
> It shouldn't be necessary to duplicate the line, but if that
> solved the problem (and I don't think it would),
> then Tbird is clearly broken and needs
> attention by a developer. Having a working import facility
> is important and the fact that Tbird didn't have a
> working one until recently caused me not to move from
> Eudora to Tbird until it worked.
>
> And it can be worth the trouble if I have a lot of names.
> In emacs, I can do all sorts of reformatting to get a list
> of emails into a format that should be acceptable to the import.
> My test case was just to illustrate the problem. When
> debugging, the smaller a test case the better.
>
> Is there a forum someplace where bugs should be posted?
> I'm pretty convinced that this is a bug.
Sorry paul - thats all I got.
I outa here
regards:captjlddavis
Why don't you report it as a bug at Bugzilla and see what happens?
https://bugzilla.mozilla.org/
(After first searching to determine if it was prior reported.)
Miles
Please do, I doubt there is a bug already filed for this. Can you also
please attach an example file that exhibits the problem - it is
important to attach a file as then we have a specific test case and we
know we are using exactly the same thing as you are (if you can't attach
it straight away, submit the bug and then go into it and attach it after.
Standard8
Please post a bug & attachment!!
Günter
One more ride on this pony.
I personally think it is not a "bug". It does what is supposed to
do.Though Very clumsy.
To quote from Cool Hand Luke...
"What we have here is a failure to comunicate..."
Using Pauls data from above, I edited it to show the top line defining
the field order. I added two more records. I edited his email address
to correct format.I saved it as book name "test1"
Final test1.csv file as follows:
"Primary email","first name","last name","display name"
"em...@noplace.net","first name","last name","phone"
"some...@somewhere.com","Arthur","Somebody","Arthur Somebody"
"some...@somewhere.com","Bobby","Somebodyelse","Bobby Somebodyelse"
"sle...@hollow.com","Rip","VanWinkle","Rip VanWilkle"
"sle...@hollow.com","Rip1","VanWinkle1","Rip VanWilkle1"
I opened Tb and adjusted data to correspond to field name - unchecked
unwanted fields - imported .csv file = test1
I imported it and it works.
It shows 5 records(entries) with correct data.
First line on .csv file IS not displayed as a record.
If I haven't screwed up writing it down, this is what I did and it works.
Thats my story and I am sticking with it.
regards:captjlddavis
OK, I grabbed your example, and the mapping window is still screwed
up, but you're right, it does seem to do the right thing with
the eventual import into the right fields if you click past it.
So it looks like the bug (and I believe it's a bug) is that when Tbird
populates the field mapping window, the right column list should
terminate at the first CRLF, but if there are 4 or more fields, it
continues displaying the 'real' records after the header names as
if they were more field names in the header record list.
I did report it on bugzilla as somebody suggested and will update
it with this new information.
Thanks to all!
Have you got a BUG number ?
regrds:captjlddavis
edit to read:
Primary email,first name,last name,display name
em...@noplace.net,first name,last name,phone
some...@somewhere.com,Arthur,Somebody,Arthur Somebody
some...@somewhere.com,Bobby,Somebodyelse,Bobby Somebodyelse
sle...@hollow.com,Rip,VanWinkle,Rip VanWilkle
sle...@hollow.com,Rip1,VanWinkle1,Rip VanWilkle1
when TB exports as .csv - no quotes marks.
please let me know ?
regards:captjlddavis
At least with the def-line NO quotes! Just tryed, works.
A general note:
The TB/AB may have problems with CSV importing including tabs. That was
driving me crazy when exporting from Outlook with CSV format and
importing into TB/AB.
(Here OL "Description" records haveing
Finally I found working with LDIF is much better here. Because you
generate the file by some other progs, why not using LDIF??
Günter
And I never tried tab-separated input.
Re: LDIF
I didn't have a program to generate that format, I figured
it was easier to get what I wanted out of emacs.
Thanks! I'll update the bug report with this inf.