On Mon, Feb 9, 2015 at 4:29 AM, Laurie Alvey <[email protected]> wrote: > > Short of manually creating the SQL Server objects and importing from flat > files, any ideas?
This. My experience might not map exactly to what you're doing, but I've done a couple migrations and always seem to stub my toes on the same items. I'm currently in the tenth month of a project where we are weaning a client off a monolithic single-user FoxPro app + DBFs into a multi-tier app on PostgreSQL with a web component and a much more limited Fox app. My technique was to move the app in 3 parts, and automate each of them: 1) Structure: GENDBC is your friend, GENDBCX even better: generate the hard structure of the application by editing out the irrelevant statements from a GENDBC or X output and saving it as a .SQL file. You can load this up over and over as the structure changes. 2) The data: write a quick script that outputs the contents of each table into an appropriate format. Write a second script that loads data into the server, one table to a method. Big fan of CSV, but had to use DELIMITED for a couple with embedded quotation marks in text or other issues. JSON and XML work, too: any text format you can further manipulate in VFP is a big win. 3) The relations: in a lot of cases, I've found VFP data has alphabetic keys, short integers, or other numbers that need to be changed into auto-inc integers or GUIDS. For this reason, I leave the loading of the data in #2 as plain text into standalone tables, and then a separate script that links the tables together, often generating new keys, and then declaring relations. I've found in many cases that data has to be repaired, and by separating the process into a couple of steps it's easier to script those things: changing empty dates to NULL, modifying strings or memos to varchars, etc. And some data might not be fully normalized and need to be changed. And, of course, the client is paying for a migration for a reason, and it's likely you can add additional features, table structures, in this process. By separating the migration into the steps above, and recognizing that migration is a *separate application development process* and one you're likely to run over and over again as you learn more about the data, P.S. Sounds like this would be a great magazine article :) -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ 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/CACW6n4u9n_hOsp4B8wXW7spF8USs2_mCysuj=cjxrr+jo5t...@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.
