Leland Jackson wrote:
Why wouldn't you want MySQL to handle all the heavy lifting of the data, including parent and child tables, auto-incrementing of primary keys, all indexes, all foreign key constrains (eg RI), all processing within transactions, etc? Then MySQL would retrun a record set based on SQL 92 to the VFP GUI. The data could be manipulated with the VFP GUI/Program, and then updated back to MySQL.
And that's absolutely what I'm doing. I use a tiered design so that VFP GUI simply expects a cursor, and the DataObject is responsible for creating that cursor, whether that means opening a VFP view or doing a SPT call against the non-VFP database to create the cursor (and then using Paul McNett's MakeUpdatable.prg code to make the SPT cursor updatable like a view---see Ed's downloads section for Paul's code if you're interested....slick!).
Eventually, I want to move it all to MySQL, but don't have the resources to do that all at once now, as I have clients using the app now, and am favoring a gradual approach where new features are implemented using the MySQL backend instead of VFP.
-- Michael J. Babcock, MCP MB Software Solutions, LLC http://mbsoftwaresolutions.com http://fabmate.com "Work smarter, not harder, with MBSS custom software solutions!" _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
