You don't specify, but I'm guessing the rewrite is likely not going to
be in VFP.
I've done a couple of migrations from local tables to client-server,
although mine were MaxFrame and West-Wind, so I can't speak to
specific issues with VPM or Codemine, but...
1. I've never run into a migration that doesn't include at least one
"while we're at it, let's fix the normalization of..." or other schema
changes. These need to be recognized as significant changes,
potentially scope changes, potentially showstoppers, and need to be
handled like Change Orders: estimated, scoped, signed-off.
2. A migration is typically run a couple of dozen (hundred) times
until you get it all right, and then never again, a bit of an
inversion from other kinds of app development, but most of the same
rules apply: you're building an application. You need a project plan,
source code control, testing, development and production versions.
Plan on running the migration over and over until you get it right and
set it up with instrumentation and logging so you can figure out why
and when it goes off the rails, until it works.
Along with changing the code of the main app to support the new data
backend, you will be writing a migration app. You won't know at the
beginning which one will be more complex or take more time to
complete. Any changes to the schema is going to require changes in the
main application: fieldname changes, defaults, size changes,
empty/null handling.
3. "Upsizing' is an ETL function: Extract, Translate, Load, and you
are doing it twice: once for the schema, and once for the data. The
schema is going to change because datatypes have subtle differences,
the new server may have different definitions of keys and relations
and triggers. The data is going to change because default storage and
data ranges will be different (there's no EMPTY() on most data storage
engines, and NULL means a very different thing from a blank field.
Sometimes you need both.) You'll have to handle empty date fields. You
will find junk in your data: numeric fields that somehow overflowed
silently ("My God, It's Full of Stars.") and memo fields with
corrupted storage and impossible dates. There is always junk in the
data, perhaps in an order from 1988 that no one looks at any more that
got screwed up in the Great Crash of '94, but it will make your
migration app crash.
4. Last, re: framework-specific questions. As I said above, no direct
experience with migration those two, though we did use VPM on a
project in the late 90s.
I wasn't clear from your original post whether you were familiar with
the frameworks. At the least, you'll want access to all the
documentation. I did a lot of work with Codebook and Maxframe and like
most tools, you become more skilled with practice. The first one tends
to be the most difficult. Hopefully your clients can supply some
expertise there.
On Fri, Jul 22, 2016 at 10:00 AM, Tracy Pearson <[email protected]> wrote:
> A couple different projects I know about are looking to convert from using
> DBFs to an SQL backend.
>
> One project is using the Visual ProMatrix framework.
> The other is using Codemine.
>
> If you have any input about a transition with these, please speak up.
>
> Thank you.
>
>
[excessive quoting removed by server]
_______________________________________________
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/cacw6n4t-glh8wl1sl1c+wa2dajud5rmh1psuutqw3ecge1m...@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.
