Synchronize Treo650 palm cellphone pda with flat ASCII csv text file

[uyhujik]

How do we synchronize palm contacts with a plain old ASCII csv file?

Here's as much information as I think you'd need to help me:
--- BASICS:
- I maintain my personal contacts in EMACS (as a comma-delimited text
file)
- I use one line per contact with six fields
(last,first,cell,home,work,email)
- My phone is a Verizon Treo650 and I use 100% Verizon-supplied
software
- My operating system is Windows XP SP2
- I do not wish to mix personal contacts with business (i.e., Outlook)!

--- SOFTWARE:
- Verizon does not recommend the use of Chapura PocketMirror
- My Outlook conduit is the free Verizon Tre0650 Palm Conduit
- My desktop is the free Verizon Treo650 Palm Desktop 4.1E
- My hotsync manager is the free Verizon Treo650 HotSync Manager 6.0.1
- All three free software packages come from the Verizon website:
- http://www.palm.com/us/support/downloads/windesk414e.html

--- USEMODEL:
- I only wish to use Outlook for Calendaring at work because I must
- I only wish to use the Treo650 for personal telephone & business
calendaring
- I don't use the Palm Desktop for anything (that I know of)

--- OBSERVATIONS:
- Apparently I can syncronize with either Outlook or the Palm Desktop
- Apparently I can not synchronize with both Outlook & the Palm Desktop
- I do not know how to synchronize with a plain old ASCII text csv
file!

--- FILES:
- I have no problem maintaining my contacts in EMACS as a flat csv file
- I've been maintaining my contacts in that ASCII file for over twenty
years
- All I want is to synchronize (both ways) that file with my Treo650
pda cellphone

--- PROBLEM:
How do we synchronize our PDA telephone (both ways) with a c:\phone.csv
file?

 

[uyhujik]

How do we synchronize palm contacts with a plain old ASCII csv file?

How do we synchronize our Palm PDA with a c:\phone.csv file?

I forgot to mention that, as a lousy workaround, I imported the csv
file into Outlook as a Contact and that is how I currently synchronize
my c:\phone.csv file with my Treo650 PDA.

--- MY (lousy) WORKAROUND:
1. First I edit my phone.csv file in EMACS to make any additions or
deletions.
2. Then I import that phone.csv file into Outlook 2002 (multiple silly
steps).
3. Then I synchronize with the Treo650
4. I then immediately delete the Outlook contacts

This (lousy workaround) keeps private data separate from company data.
Why can't I just synchronize with the ASCII text csv file I've been
maintaining for over 20 years?
What key step am I missing?

Note: All I want Outlook for is calendaring (which is mandatory at my
company).
Note: All I want the Treo650 Palm PDA for is telephony & calendaring.
Note: I'm perfectly happy maintaining my phone.csv file using EMACS.

Do you know how to synchronize contacts with a plain old ASCII csv text
file?

 

[Boris T. Gunner]

It can't be done. Nobody can syncronize to a plaintext file.

I ran a search to find a lot of people ask for this but nobody can
syncronize to a file of any fomat.

The only way to syncronize is to the desktop or to outlook, both of
which are not what you asked for.

 

[John]

I forgot to mention that, as a lousy workaround, I imported the csv
file into Outlook as a Contact and that is how I currently synchronize
my c:\phone.csv file with my Treo650 PDA.

--- MY (lousy) WORKAROUND:
1. First I edit my phone.csv file in EMACS to make any additions or
deletions.
2. Then I import that phone.csv file into Outlook 2002 (multiple silly
steps).
3. Then I synchronize with the Treo650
4. I then immediately delete the Outlook contacts

This (lousy workaround) keeps private data separate from company data.
Why can't I just synchronize with the ASCII text csv file I've been
maintaining for over 20 years?
What key step am I missing?

Note: All I want Outlook for is calendaring (which is mandatory at my
company).
Note: All I want the Treo650 Palm PDA for is telephony & calendaring.
Note: I'm perfectly happy maintaining my phone.csv file using EMACS.

Do you know how to synchronize contacts with a plain old ASCII csv text
file?

Palm doesn't understand "plain old ASCII".
It's not DOS/Windows/Linux; it doesn't have a *real* file system; and
it doesn't read/write text files.
Welcome to Palm OS ;-)

The Palm Desktop can import csv files into Contacts (check that the
field order is correct) and they will be transferred to the Palm when
you HotSync.

John

 

[Tinman]

Palm doesn't understand "plain old ASCII".

To expect to sync--not just import--a text file you originally created
two-decades-ago is a bit unrealistic. I won't get into why someone
maintains such a bare-minimum list (5 fields?) to sync with a *PDA*
phone--when using a Windows XP PC of all things.

There are of course other work-arounds to the apparent issue of not
wanting to intermingle business calendar with personal contacts (though
I wonder what happens if one needs to call one of the attendees of an
upcoming calendar event when you don't have their phone number--call
information?).

Regardless, it's clear the only solution the OP is looking for is one
that syncs his decades-old CSV "database" to Palm's internal Contacts
database.

It's not DOS/Windows/Linux; it doesn't have a *real* file system; and
it doesn't read/write text files.

What is FATFS.prc doing and how is NVFS memory formatted?

 

[Anthony Susa]

To expect to sync--not just import--a text file you originally created
two-decades-ago is a bit unrealistic.

What are you talking about?

I maintained (note the word maintain) many databases over the years some of
which are apparently older than you are. That means they are up to date!
The word "maintain" means they are up to date. That means Uncle Joe and
Sister Susaan and High School Friend Bill are all up to date in the
database. It's the database that is important - not the platform of the day
(these PDAs are just a passing fad as I've seen many in my years).

What makes you so cocky as to presume that one can only synchronize
brand-new databases? Are you fourteen years old and therefore Windows
Outlook is the only platform you have ever known?

I've maintained databases (yes, phone lists too) starting with the IBM 370
and migrating them to the 8-inch floppy disks on DEC VMS and on to magtape
on the early Suns before moving to the Macintosh PC (up to OS8) finally on
to the new fangled IBM AT computer (at about the 80186 and 80286 & 80386
point) and onward (ever onward) up the line of DOS's & OS's like OS2 and NT
to the ephemeral style of the day today. Windows and Linux are here for
today but they, like all the others, will just be wisps in the wind five,
ten, or twenty years from now.

But, my simple record-oriented character-delimited telephone list will
still be maintained and up to date.

Who are you to presume that it is unrelistic to maintain a telephone list
of your family and friends up to date?

There are of course other work-arounds to the apparent issue of not
wanting to intermingle business calendar with personal contacts

I think that is precisely what the OP asked for.

 

[Anthony Susa]

Palm doesn't understand "plain old ASCII".
it doesn't read/write text files.
The Palm Desktop can import csv files into Contacts

I'm confused John about the apparent contradiction in your statement above.

Obviously you know that a csv file is "plain old ascii".
Obviously the palm pda can import this plain old ascii file csv file.

How can the palm os import and not import the same file?

 

[Tinman]

What are you talking about?

What is so hard to understand? I assumed anyone with an IQ above room
temperature, who had any knowledge of computers at all, would not need
further clarification.

I maintained (note the word maintain)

Yes. In particularly, I noted that you seem to have little grasp of the
concept of "tense."

many databases over the years
some of which are apparently older than you are.

I see. Might I assume you used the Psychic Friends Network to ascertain
how old I am? Or did you just make another blind uneducated guess?

That means they are
up to date! The word "maintain" means they are up to date. That means
Uncle Joe and Sister Susaan and High School Friend Bill are all up to
date in the database.

Noooo? Really? In my world, where I actually use a Treo 650, I have
these little things like addresses, email addresses--and much more--that
I'd like to be able to access for each contact right on my Treo--yep,
even personal contacts. How can I do that with five fields?

It's the database that is important - not the
platform of the day (these PDAs are just a passing fad as I've seen
many in my years).

The post was about a PDA phone. But don't let that fact stop you while
you are on a roll...

What makes you so cocky as to presume that one can only synchronize
brand-new databases? Are you fourteen years old and therefore Windows
Outlook is the only platform you have ever known?

Yep, I'm fourteen-years-old and Outlook is the only platform I've ever
know. You are physic, aren't you?

But, my simple record-oriented character-delimited telephone list will
still be maintained and up to date.

Who are you to presume that it is unrelistic to maintain a telephone
list of your family and friends up to date?

In a digital world you either keep up or become a dinosaur (not that I
am calling anyone a dinosaur--I surely would never do that).

I think that is precisely what the OP asked for.

Then by all means tell him the answer!

 

[Anthona Susa]

Noooo? Really? In my world, where I actually use a Treo 650, I have
these little things like addresses, email addresses--and much more--that
I'd like to be able to access for each contact right on my Treo--yep,
even personal contacts. How can I do that with five fields?

Uh, so you add fields to your text file. What's the big deal.

last,name,middle,company,title,address,phone,cell,fax,email,, CR
last,,first,,title,address,phone,cell,fax,email,birthday, CR
last,,first,company,,address,phone,cell,fax,email,,cell2 CR
etc.

My ascii text databases can have as many fields as they like. Each field is
delimited by a semicolon (instead of a comma) and each record is delimited
by a carriage return. What's so hard about that? This simplicity allows for
as many fields as you care to maintain and the databases last for decades
like any good database should. In fact, an ascii text database (csv if you
will) has no wear-out mechanism so they don't depend on fashions as
ephemeral as the platform of the day (and I've seen dozens of these
platfoms, currently Outlook & Palm, come and go over time yet the time
honored ascii databases remain as long as they are maintained properly).

Then by all means tell him the answer!

I think it's clear that neither you nor I know how to synchronize a palm
pda to a single contacts file. Unfortunately, we're the only ones posting,
which isn't going to help anyone else but feed our egos to see our names in
print.

I, for one, suspect there is a trivially simple way to synchronize a palm
pda contact file with an ascii text (csv if you will) character-delimited
contacts file - but I don't know how.

Does anyone anywhere know how to synchronize a palm pda to a contacts file
without using outlook or the palm desktop? I certainly don't.

 

[Tinman]

Uh, so you add fields to your text file.

"My" text file? Uh, no. The OP was the one who clearly indicated the
number of '80s-era fields he uses (though it is 6, not 5--presumably the
'90s brought about a monumental schema change in order to accommodate
cellphone numbers ;-)).

My ascii text databases can have as many fields as they like.

As I'm rather certain your text files are not self-aware, it might be
better to state that your databases can have as many fields as you
like--and even then that's only if the app reading them supports an
"infinite" number of fields.

But seriously, did you really not comprehend it was the OP using 6
fields by choice?

In
fact, an ascii text database (csv if you will) has no wear-out
mechanism so they don't depend on fashions as ephemeral as the
platform of the day (and I've seen dozens of these platfoms,
currently Outlook & Palm, come and go over time yet the time honored
ascii databases remain as long as they are maintained properly).

Any good database application will have forward and backward
portability. Last I checked both Outlook, Palm Desktop, and hundreds--if
not thousands--of other applications can both import and export CSV
files (as well as other formats--e.g., DBF). The same is true for most
enterprise database applications.

This ain't rocket surgery. And whether it is a DVD, CD, floppy disk, or
50-year-old magnetic tape a future human being will simply not be able
to read it without the use of a machine. Period.

I think it's clear that neither you nor I know how to synchronize a
palm pda to a single contacts file.

You have no idea what I know; or do not know. I'm not even sure you
fully understand the issue with syncing--not just overwriting--a 6 field
ASCII CSV data file with the Treo 650's native Contacts app. This
appears to be what the OP is wanting to do.

Unfortunately, we're the only
ones posting,
which isn't going to help anyone else but feed our egos
to see our names in print.

For the record, I did not intend to get into this debate. In my first
post to this thread (which was not to the OP), I stated "I won't get
into why someone maintains such a bare-minimum list (5 fields?) to sync
with a PDA phone--when using a Windows XP PC of all things." [should
have been "6 fields"]

I'll have to assume you took that to mean I really did want to get into
it, and that I have no knowledge of CSV/TSV files whatsoever.

I, for one, suspect there is a trivially simple way to synchronize a
palm pda contact file with an ascii text (csv if you will)
character-delimited contacts file - but I don't know how.

"Trivially simply?" The OP is apparently asking to sync a 6 field ASCII
CSV file to the Treo's Contacts app. Further he seems to want to still
use EMACS to maintain that file on the PC-side (i.e., he wants real
syncing).

Considering the 6 fields now contained in the file, how exactly is this
"trivial" conduit supposed to know when a specific record has been
updated by the Treo so it can update the correct record on the PC? Can
we add a field to indicate a record's data is dirty--and what will EMACS
do with such a field if a record is updated by EMACS?

Or, is the conduit supposed to compare the entire text file to look for
changes? If so, can it target specific records? And how will the conduit
reliably identify records? By Record ID? If the CSV file doesn't contain
it, it will need to be created in the Contact's database. Will this
Record ID propagate back to the CSV file? Where? How will EMACS maintain
it, particularly on new records. Will it enforce this key?

So while a sync conduit for CSV files may be possible, I don't think
it's as easy as you think--especially if EMACS is still going to be used
to edit the file on the PC-side. And for a true--and reliable--sync the
file will need additional fields (and I don't mean an extra email
address or two).

All of these hurdles in order to cling to a decades-old CSV file? Fine.
Have fun with it.

 

[null]

(e-mail address removed) wrote in @o13g2000cwo.googlegroups.com:

I forgot to mention that, as a lousy workaround, I imported the csv
file into Outlook as a Contact and that is how I currently synchronize
my c:\phone.csv file with my Treo650 PDA.

--- MY (lousy) WORKAROUND:
1. First I edit my phone.csv file in EMACS to make any additions or
deletions.
2. Then I import that phone.csv file into Outlook 2002 (multiple silly
steps).
3. Then I synchronize with the Treo650
4. I then immediately delete the Outlook contacts

This (lousy workaround) keeps private data separate from company data.
Why can't I just synchronize with the ASCII text csv file I've been
maintaining for over 20 years?
What key step am I missing?

Note: All I want Outlook for is calendaring (which is mandatory at my
company).
Note: All I want the Treo650 Palm PDA for is telephony & calendaring.
Note: I'm perfectly happy maintaining my phone.csv file using EMACS.

Do you know how to synchronize contacts with a plain old ASCII csv text
file?

I actually wrote a conduit to do that once. I got the current contact
list database, parsed it out into an intermediate csv file, parsed the
csv I wanted (the name of the file was read from an external .ini
file...I was lazy and didn't want to do a UI ;P ) into my csv file,
merged the records into my intermediate file, then converted it back to a
Palm database and synched it back up to the handheld. Not a super slick
solution, but it seemed at the time to be the safest and most
straightforward way to do it. It's not hard, it's all Win32/C++ code.

However, it's not especally easy to do, but it can be done.
Unfortunately, don't ask me for the source code, as it was claimed by a
company I worked for. As far as I know, they've never bothered to
release it, so it's probably just sitting somewhere on a tape drive
source archive.

-Null

 

[Tony Susa]

Considering the 6 fields now contained in the file, how exactly is this
"trivial" conduit supposed to know when a specific record has been
updated by the Treo so it can update the correct record on the PC? Can
we add a field to indicate a record's data is dirty--and what will EMACS
do with such a field if a record is updated by EMACS?
Or, is the conduit supposed to compare the entire text file to look for
changes? If so, can it target specific records? And how will the conduit
reliably identify records? By Record ID? If the CSV file doesn't contain
it, it will need to be created in the Contact's database. Will this
Record ID propagate back to the CSV file? Where? How will EMACS maintain
it, particularly on new records. Will it enforce this key?

Hi Tinman,

Ever since my extensive contact list in MultiMate DBASE III died on me,
I've learned from expertience to rely on an ascii text contact list that
transcends the fashion of the day.

Seems to me this approach outlined below is feasible (if not perfect). What
do you think? It assumes my particular work style which is to synchronize
morning and afternoon and to makes changes in the office to the master.csv
file and to make changes away from the office to the palm pda contacts
list.

ASSUME USER KNOWS HE MODIFIED THE MASTER.CSV ON THE COMPUTER:
A. User imports master.csv to Palm Desktop or Outlook contacts
B. User hotsyncs "Desktop overwrites handheld" (no duplicates)
C. User deletes contacts in Palm Desktop or Outlook contacts

ASSUME USER KNOWS HE MODIFIED THE PALM HANDHELD PDA CONTACTS:
A. User hotsyncs "Handheld overwrites desktop" (no duplicates)
B. User exports (1 line per record) master.csv to the computer
C. User deletes contacts in Palm Desktop or Outlook contacts

PROS:
a. Allows user to maintain contacts in a flat ascii text file
b. Contacts list is always complete & up to date after hotsync
c. Personal & business contacts are only mixed momentarily

CONS:
a. Hotsync copies the entire contact list every time
b. Disallows BOTH master & portable lists changing at same time
c. ?

Except for one minor glitch, this approach seems to work in my use model.
Since the number of records is small, copying the whole contact list takes
seconds (about five seconds or so). The major risk is the requirement that
only one side change at a time. This is impossible in my working
environment so it is not of concern to me (YMMV).

In my working environment, I hotsync by cable every morning and afternoon
as I arrive and leave from work. During the work day, I modify the
master.csv file (if necessary). The computer is actually a Linux server
tied to the desktop PC via Samba. At the end of the work day, I download
those changes (if any) to the Palm PDA. When I'm away from the office, I
modify the Palm pda contact list. Back at work, I upload those changes and
the cycle resumes.

This approach allows one to easily maintain (on any platform) an ascii text
contact list that will never go out of date due to platform or software
changes.

 

[Tinman]

Hi Tinman,

Ever since my extensive contact list in MultiMate DBASE III died on
me, I've learned from expertience to rely on an ascii text contact
list that transcends the fashion of the day.

Why not go all the way, and etch them into stone tablets? ;-)

But seriously, as a database programmer I've been managing, and creating
(hopefully idiot-proof) front-ends for, databases for nearly two
decades. The only time I have ever seen true data loss is when the
user/IT/DB Mgr failed to maintain proper backups.

And as many of my projects involve(d) integrating disparate systems, I
have used CSV/TSV/you-name-it files as transfer mechanisms for years.
Though generally temporary in nature, some of these have been lost too
(e.g., system failure) and would have been irretrievable if it weren't
for backups.

Regardless, I have systems running today that have records dating back
to the 1970s--surviving several itinerations of conversion. My own
contacts database dates back to the early-to-mid '80s--and it was mobile
via an early Casio Digital Diary (with the data-transfer cable and all).

Today they are in more-modern formats--and most can still be converted
to ASCII CSV, if needed. But as I use the Notes field extensively
(within Contacts) on my Palm (Treo 650), this would get ugly--and
neither Outlook nor Palm Desktop appear to support XML.

Instead I can use Outlook to export my Contacts database as an MDB file,
and nearly every field (no contact photos) comes over intact (e.g.,
CRs/LFs in my Notes are retained). I can then use MS Access to export
the database as XML--again, with my Notes intact. Is this not ASCII
text?

I can also export to SQL or just about any format used over the last
decade or two.

So I don't get this whole paranoia thing about CSV being the only true
way to maintain reliable data. We'll have to agree to disagree.

Seems to me this approach outlined below is feasible (if not
perfect). What do you think?

I think it's the exact same thing the OP described in his follow-up post
as a "lousy workaround" (his words, not mine). It is not syncing, that's
for sure. It also requires the user to remember to change the Hotsync
Contacts' conduit for each sync. And the part about taking 5 seconds is
kind of like saying it only took 15 minutes to paint a room--when the
preparation and clean-up took 3 hours. There is still the cumbersome
process of manually importing and exporting the text file for each and
every "sync."

But to each his own.