Synchronize Treo650 palm cellphone pda with flat ASCII csv text file
uyh...@yahoo.com
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?
uyh...@yahoo.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?
Boris T. Gunner
>> How do we synchronize palm contacts with a plain old ASCII csv file?
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
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
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?
--
Mike
Anthony Susa
>>> Why can't I just synchronize with the ASCII text csv file I've
>>> been maintaining for over 20 years?
> 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".
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
> On Sun, 4 Dec 2005 11:06:01 -0700, Tinman wrote:
>>>> Why can't I just synchronize with the ASCII text csv file I've
>>>> been maintaining for over 20 years?
>> 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?
>
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).
>> 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.
Then by all means tell him the answer!
--
Mike
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).
>> I think that is precisely what the OP asked for.
> 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
> On Sun, 4 Dec 2005 16:06:28 -0700, Tinman wrote:
>> 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.
"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 that is precisely what the OP asked for.
>> 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.
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.
--
Mike
null
@o13g2000cwo.googlegroups.com:
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
Jd Lyall
asserted.
If it (desktop, a windoze application) can re-import without duplicating
records (I have no idea) then this looks like it may be a solution.
Dale DePriest
Jd Lyall wrote:
He didn't say that. He said the Palm itself cannot import a .txt file
but that the pc half of the Palm (called the Desktop) could import the
text file as a memo and then it could be sent to the Palm.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
Tony Susa
> He said the Palm itself cannot import a .txt file
> but that the pc half of the Palm (called the Desktop) could import the
> text file as a memo and then it could be sent to the Palm.
Hi Dale,
I met you once, long ago, in the south bay. You were testing out various
handheld GPS equipment attached to your car. You're a good guy and I
appreciate the advice.
I'm a bit confused about importing the text file as a memo.
Can it then be used for the Palm contacts list dialing?
If so, great - that would be the solution - however I suspect not.
Tony Susa
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.
Dale DePriest
Hi Tony,
I think I may have added to the confusion. The topic drifted a bit from
the original idea of contact lists to the more general question of how
to import text files to a palm. I see you have corrected this back to
the original question.
As to importing a contact list to the Palm Treo you have to go through
some conduit to get it in a form the Palm can understand. This is
basically true of everything you send to the Palm for storage in RAM.
Information stored on SD cards are not as restrictive but you cannot
store your contacts there. Anyway, the point is you have to convert the
data on a computer before importing it. The Palm address book is one way
to do this. Another is to use a third party program to provide a conduit
to other address book methods such as Outlook or Netscape. The idea is
that you import the data into the address book on the PC or other
computer and then you use the Palm desktop (or potential some third
party desktop) controlling a conduit to send the data to the Palm.
There are programs available to get csv data into some address books on
the pc including the ability of the programs themselves to import the
data. Outlook can import CSV data for example. Then you using something
like Intellisync to get the data to the palm.
Does this cover the ground?
Tinman
> On Mon, 5 Dec 2005 04:52:32 -0700, Tinman wrote:
>> 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.
>
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.
--
Mike
Tinman
>
> There are programs available to get csv data into some address books
> on the pc including the ability of the programs themselves to import
> the data. Outlook can import CSV data for example. Then you using
> something like Intellisync to get the data to the palm.
>
> Does this cover the ground?
>
Only if you didn't read the OP's first two posts that started this
thread.
--
Mike
Tinman
>
> I'm a bit confused about importing the text file as a memo.
> Can it then be used for the Palm contacts list dialing?
Yea if you don't mind manually scanning the list to locate the person
you want to call (no find function within a Memo) and then
copying-and-pasting the number into the Phone app. Sounds fun.
> If so, great - that would be the solution - however I suspect not.
>
You would be correct.
IMO, as the OP is using a PDA phone, and his CSV file is actually named
"phone.csv" it would seem rather absurd to not be able to use the
database with the phone (not to mention manually maintaining the file).
And if that were an acceptable solution, the OP probably (not sure about
Verizon Treo 650s) received Documents-to-Go on his Treo's CD (not that
you can't just buy it).
That application will allow true to syncing to a text file--no need to
import anything as a memo. I myself have several text files that I keep
synced on both my Treo and PCs by Docs2Go (and the text files are synced
while being stored on the Treo's SD card). As a bonus, Docs2Go lets you
search within individual files--including text files!
But again, that approach seems rather pointless for a phone database
used with a PDA phone.
YMMV.
--
Mike