If you are fluent with VFP, you might consider building your own SIMPLIFIED framework. Most commercial frameworks are way too complicated.

Commercial frameworks are good if and only if your needs are simple. When you need to do heavy customization, it would be as messy as if there was no framework. :)

On Fri, Jul 22, 2016 at 10:00 PM, Tracy Pearson tracy@powerchurch.com 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.

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 tracy@powerchurch.com 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]