On 2/23/14, 8:25 AM, Ted Roche wrote:
How 'bout that? An on-topic question!
I need to upload/download small (10-100 records) batches of data between a
web application (likely Ruby, maybe PHP) and a VFP application.
On the one hand, JSON is great for interchange because of its compaction
ability (if you do away with readability), its readability (if you do
away with compactness), its general acceptance, and its flexibility. On
the other hand, perhaps CSV should be considered as well, for ease
importing the data into VFP. I don't know, there's probably some VFP
json library available now, but VFP's import/export from/to CSV I
remember being pretty excellent, easy, and fast.
Data is
straight-forward, 3 simple tables of data: customers names and addresses,
order details and some numeric constant-ishes. The idea is that the web app
assigns a batch of customers, the sales guy downloads the data to their
portable VFP apps, load it up, and visit the customer sites, where internet
of any form (cellular, wireless, wired, modem) is not available. Data is
gathered/updated, and later (when internet available) tabular data loaded
back up to the mothership, overwriting existing records.
Seems like you are also going to want some sort of merging smartness so
that one salesperson can't overwrite another's history just because he
added a phone number (extreme example).
VFP is a bridging technology; I want the import/export to be generic enough
that other devices (iPad, Android, WinTab) might be used in future versions
with minimal recoding. My thoughts are that the two compatible formats
these days are JSON and XML.
JSON or CSV. I wouldn't even consider XML for this. Client database
should be SQLite (connect with ODBC from VFP), perhaps even doing that
now to avoid headaches later, like with conflicting encodings (SQLite is
UTF-8 by default even on Windows, none of the legacy ansi mess).
1. Anyone doing something like this? What techniques/technologies are you
using?
I have a python desktop app in the field that has a single-user mode.
Client database is SQLite with data merging with the mothership's MySQL
data using a custom web service that transfers SQL statements. Yeah, I
know. I did this in 2007, what can I say. Today, I'd use JSON as the
interchange format. It works very well.
If you can, use UUID primary keys, so that your salesguy can create new
records that have no chance of colliding with records on the mothership.
VFP can do CursorToXML() and the reverse. Problems?
Yeah, the XML. ;)
2. Problems with translating character data between web app (typically
UTF-8) and FoxPro (ASCII/ANSI Windows code pages)?
You WILL run into encoding/decoding issues if you don't address this up
front. Can VFP tables store in utf-8? If not, choose a database that
can, especially since it'll be a requirement later on (sqlite on devices).
Customer data will
likely be Euro-American English (accents, tildes, umlauts, etc.) suitable
for US Postal delivery, so not Persian, Cyrilic or Asian character sets.
I'm pretty sure CursorToXML should handle encoding back-and-forth pretty
well.
I'm not sure about this, but you might be correct. I guess you could
find out. :)
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
