Re: Transitioning from VFP backend to MySQL
Two sentences, 31 words and 46 words, respectively, not expanding contractions. MB: Take a deep breath. Talk slowly. Small sentences. What caveats? Using MySQL means you don't have to pack, it's easier to delete and insert than to reckon what's changed and mix delete/insert/update logic, that transactions work more reliably (InnoDB) and with point-in-time recovery. Explain what you mean about synchronization. What are you looking for here? What are your questions? -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ Post Messages to: ProFox@leafe.com 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.
Re: Transitioning from VFP backend to MySQL
Ted Roche wrote: Two sentences, 31 words and 46 words, respectively, not expanding contractions. MB: Take a deep breath. Talk slowly. Small sentences. Brevity was always a challenge for me. Bill and I perhaps share that in common. haha---jk Bill! What caveats? Using MySQL means you don't have to pack, it's easier to delete and insert than to reckon what's changed and mix delete/insert/update logic, that transactions work more reliably (InnoDB) and with point-in-time recovery. No no, I know all the good reasons of why to use MySQL...that's not what I meant. Explain what you mean about synchronization. What are you looking for here? What are your questions? When shops have tried to use a combination of VFP and SQL Server, it's caused a lot of pain in terms of making sure the VFP data shakes well with the SQL Server data. Now in those instances, they probably didn't normalize enough and hence they needed to make repetitive changes to make sure the VFP and SQL Server values were the same (sync-ed). In my system, I'm integrating user administration where the MySQL tables hold the user ids, rights, etc. Some of the MySQL data (userid or some unique integer keys for example) will be saved in the VFP tables. I don't see a real harm with thatdo you? Is there a best strategy for migrating an existing, in-use app from VFP to a non-VFP backend (in my case, MySQL)? breathing out... -- 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: ProFox@leafe.com 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.
Re: Transitioning from VFP backend to MySQL
Ted Roche wrote: snipped In MySQL (and every other data engine without the RECALL command), PACKing is rarely if ever needed, so you can DELETE the whole batch of fred2types M:M records and create a new set without concern. The only concern would be if there are sibling or child records elsewhere that were pointing back to the Primary Key values for those records you just replaced with new ones. -- 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: ProFox@leafe.com 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.
Re: Transitioning from VFP backend to MySQL
On 6/20/06, MB Software Solutions [EMAIL PROTECTED] wrote: Is there a best strategy for migrating an existing, in-use app from VFP to a non-VFP backend (in my case, MySQL)? Much better - thanks! There are a lot of best strategies, one per situation (the old consultant It Depends ploy). Ideally, you have a fully normalized application and you have been using some consistent method to manage the data. Views, CursorAdaptors, your own custom data manager class, whatever. In the best of all possible worlds, you add another driver to your data manager that knows how to talk to MySQL. You convert a batch of data tables from DBF to MySQL - a batch being a set of densely related tables with more connections between them than to the outer world, like all the A/R tables, for example. A module. Then, you tell your data manager to use its remote driver to talk to A/R instead of the DBF driver. MSFT used to dog and pony this with changing all the local views (lv_customer) to remote views (rv_customer) with no other changes needed to the system. I've seen Andy Kramek do the same with his data classes, and Doug Hennig show off similar ideas with CursorAdaptors. In the best of all possible worlds, that's a nice idea. Years ago, converting one web site from DBF to SQL server, I changed all the inline code to calls to a data manager to return a cursor for processing. Then I added a table with columns for DBF SQL and one for SQL SQL and when I'd converted them all, I switched. It works. Luck happens like that, once or twice in a lifetime. The devil's in the details, of course. If you have RI between the two systems, you're going to need to hand-code that. And transactions between the two backends can be an issue, which is why you'd like the module at a time technique above. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ Post Messages to: ProFox@leafe.com 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.
Re: Transitioning from VFP backend to MySQL
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. Regards, LelandJ MB Software Solutions wrote: Ted Roche wrote: Two sentences, 31 words and 46 words, respectively, not expanding contractions. MB: Take a deep breath. Talk slowly. Small sentences. Brevity was always a challenge for me. Bill and I perhaps share that in common. haha---jk Bill! What caveats? Using MySQL means you don't have to pack, it's easier to delete and insert than to reckon what's changed and mix delete/insert/update logic, that transactions work more reliably (InnoDB) and with point-in-time recovery. No no, I know all the good reasons of why to use MySQL...that's not what I meant. Explain what you mean about synchronization. What are you looking for here? What are your questions? When shops have tried to use a combination of VFP and SQL Server, it's caused a lot of pain in terms of making sure the VFP data shakes well with the SQL Server data. Now in those instances, they probably didn't normalize enough and hence they needed to make repetitive changes to make sure the VFP and SQL Server values were the same (sync-ed). In my system, I'm integrating user administration where the MySQL tables hold the user ids, rights, etc. Some of the MySQL data (userid or some unique integer keys for example) will be saved in the VFP tables. I don't see a real harm with thatdo you? Is there a best strategy for migrating an existing, in-use app from VFP to a non-VFP backend (in my case, MySQL)? breathing out... ___ Post Messages to: ProFox@leafe.com 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.
Re: Transitioning from VFP backend to MySQL
[EMAIL PROTECTED] wrote: From: MB Software Solutions [EMAIL PROTECTED] I'm putting new functionality into some software that started using VFP (and still does primarily) as the backend, but for these new things I'm creating the tables in a MySQL database. I'm aware of some caveats of doing this (like synchronization, and as such, I'm avoiding it where this would be the case but instead really just using it for lookup tables and user administration/rights), but wondered what other caveats folks might think of for this? Caveats? 1) How was your key generated in VFP data? Same as in MySQL for some tables: AutoIncrement integer keys. For others, manual key generation with GetNextID() functionality from legacy Fox examples. 2) How did you verify the key for secondary immediate use? Huh? 3) Why would you do a mix and not convert to all MySQL? Answered that already: am integrating as new stuff comes online rather than double-development (VFP for new features while building equivalent MySQL side). This should help bring it to fruition sooner, imo. 4) That reindex code is not longer going to be used. Ok...no big deal. A plus for sure with MySQL. 5) Exclusive use, what for? Right...not used in my app, so non-issue. 6) Pack This! See answer to #4 above. 7) All your code that referenced and ! deleted() will need to be changed. Never did that, so non-issue. 8) Do you know how to make MySQL backups and restore from them? Yep. 9) Do you ever truncate the ib_logfile? There are various log files in MySQL, but that's not really for this thread, is it? :-) -- 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: ProFox@leafe.com 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.
