On Mon, Feb 24, 2014 at 2:18 PM, Paul McNett <[email protected]> wrote:
> > On the one hand,... On the other hand,... > > Yeah, me, too. Just typing in (and simplifying) the problem to form the question let me look at my biases. Minimal data, a days batch, shouldn't be a bandwidth issue, so less concerned with wordiness than ease of debugging. Can always compact later if needed. CSV is okay if used right (commas, quotes, etc.) but an amazing number of products don't understand the simple rules. > 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). This is a really simple case with pessimistic locking business rules: the mothership "checks out" a record to the field guy, so no updates while it is checked out. SImple "Last Save Wins" rules for data merging. > 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). XML is just JSON with too many pointy-brackets :) CursorToXML and its obverse are built-in and testing indicates support for two-way translation of UTF8 to Windows ANSI (Emilè Cöté appears correct on both platforms) so no futzing with the horrors of STRTRAN() or STRCONV() to try to get simple accented characters. > 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. SQL Server has a fancy-schmantzy replication scheme called 'log shipping' which is essentially this, wrapped in a proprietary binary format. It's not an awful solution. I have something similar for a backchannel update on a publish-and-subscribe mechanism myself. > Today, I'd use JSON as the interchange format. It works very well. > The issue I'm seeing is the couple of JSON libs I've found for VFP seem to hand-code "foreign" character translations (they're all foreign, folks!) I don't want the whole house of cards to fall apart the first time we run into an Å. > 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. Good idea. ATM, the barebones design is for the VFP app to generate export files to disk, and then the operator manually upload later when docked. Since they could upload last nights Netflix stream instead, we're looking at quarantining and doing some sanity checks and possibly individual reviews before actual import to production tables. Volume is low enough that this is feasible, and we are replacing a huge about of manual keypunching from pencil-filled forms, so this is still an order-of-magnitude time-saver. As the app matures, I'm sure we'll automate this. > VFP can do CursorToXML() and the reverse. Problems? > > Yeah, the XML. ;) Yeah, now I have two problems :) But they're known problems, rather than unknown unknowns :) > I'm not sure about this, but you might be correct. I guess you could find > out. :) > Yeah, all will need to be sanity checked. After all, in theory, theory and practice are the same :) -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ 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/cacw6n4sny9o_7e9t2zzci9djhntzuws2hp4hod6hhc2zk5y...@mail.gmail.com ** 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.
