Convert VFP9 Database to SQL Server 2014

None that I'm aware of, and as you can imagine it's not in the best interests of most database application companies to write a bullet-proof wizard to convert a database out of their application and into a competitor's.

<Potentially stupid question>  Why was a C++ programmer to a project converting a FoxPro database to SQL Server?  Seems to me the most appropriate developer would be a SQL Server developer, or FoxPro, or both if such an animal exists.

Thanks Jim. Perhaps a better way to put it is that he's a developer know knows a number of languages, including C++. He's been studying the Foxpro app first to be familiar with it in case I disappear (been there 45 years) and second to recommend approaches to the future. We may stick with Foxpro, but this is a first tiny step to explore alternatives. Perhaps not quite ready for Gigs!

Pavel has laid it out pretty clearly and concisely above.

a C++ programmer is finding it more of a challenge than he expected to convert the database to SQL Server 2014

Based on 20+ years of development I have found that your typical VB or C++ programmer will most often 'turn up his/her nose" at anything done in Visual Foxpro (Micro$oft's 'Red-Headed Step Child') and work towards a complete change of direction just so that they can be familiar with how things work - regardless of how well things work now.

Pavel has asked:

So you should decide what is your goal

where he lays out possible paths.

Even before that I would ask:
What is the intent of the change?

Now with that intent defined, you can more clearly 'map out' the various 'paths' to possibly get there.

After having, myself, developed a few proprietary ERP/MRP systems, I can attest to the complexity involved with the application operation (not just its associated data tables).  Converting the data tables is a minuscule effort (especially when using the Upsizing Wizard) when compared to converting how the application itself operates using those data tables.

Keep in mind that 'converting' an application to another language could be like translating a book from English to Chinese.  
Since the various languages approach tasks in widely different ways, the code will not 'convert' line-for-line 'as is' into the new language.  
More often than not the application has to be totally re-developed as if 'from scratch' in the new language - only being able to use the previous application as a very general 'road map'.

Before delving into the development of a proprietary ERP/MRP system I generally recommend that the customer do a full, detailed Business Process analysis of their operations - each and every module of it and severely critique any of the "proprietary" parts to see if they are really necessary.  
Generally the customers will 'discover' that they could be using an off-the-shelf ERP/MRP system to which they have applied most (if not all) of their unique business rules.   That is - they have 'discovered' that they can operate just fine with a non-proprietary system.

Good Luck

Thanks Pcelba and Jrbbldr. Excellent points. I got the same email from Whil--very timely.
The goal is to have an app that can be supported by programmers. Web needs are nil.  At this point the main need is to accomodate EDI--very tightly integrated into the ordering, shipping and invoicing modules. If we get a new customer that wants EDI, inevitably there are tweaks needed. So I have been training a fellow on that aspect.
I agree on the need for a long hard look before a rewrite, and that the table conversion to SQL would be the easy part. We have 150 tables (no rules or triggers). It's the many thousands of lines of code and the testing required that tell me the rewrite is not the obvious answer.
We do have some proprietary costing logic, but it is the EDI integration that I suspect will be the most difficult to achieve with off the shelf systems. Could be wrong, but a brief look a year ago suggested that most small to mid-sized companies handle EDI  through a third party, with daily export and import of tables. Ours is automatic, handling 90% of order and invoice volume.
Pavel, I assume you meant "until the Win32API is not present in Windows? Any reason to think that is coming? Can Microsoft afford that many enemies?

Argh... these English negations... :-)  I never know how to combine until with the rest of the sentence so better to avoid  until ...

Yes. It should work as long as Win32API is in Windows.

And this could be valid for a long time because VB6 is still supported application and it uses Win32API.

The bigger concern for VFP is the shared files access. Sharing on local drive is still OK but sharing DBF files on mapped remote drive becomes less reliable and more problematic. Fortunately VFP application used via RDS or VFP app working as a COM server can work with data locally.

I wrote a variety of EDI modules with or without Barcodes for VFP systems many years ago and there was no problem doing that.

However many (most ??) of today's direct inter-system communications is being done via Web-Services - no longer using EDI, but instead XML or some other format.  Again no problem doing that within the VFP environment.

Regardless, if you are needing EDI, you first need to determine how many aspects of EDI you are needing to handle and how that inter-system communication will be performed.
Look at:   What Is True ERP-EDI Integration?
Some of these most likely will not be needed, but others (multiple ones??) may be needed

And, once you Create the EDI document(s), you will need to communicate it with your 'external' partner in some manner or if you Receive the EDI document(s), it will have to be received in some manner and processed appropriately within your application.  
That communications method needs to be defined.
Again, very do-able within your current VFP environment.

If we get a new customer that wants EDI, inevitably there are tweaks needed.

You should probably be open to the possibility that a new customer may want to use XML or some other more-modern means of inter-system communication.

Note: if you do a Google search for:    ERP with EDI  or  ERP integrated EDI System   you will find that a number of off-the-shelf ERP systems and/or 3rd party intermediary operations still maintain that form of communication.

Good Luck

We've already crossed that hurdle--EDI is built into the Foxpro system. We've had no requests for XML (we are a food manufacturer), but I'll check with some customers to see if it's in the future. EDI seems pretty well-eentrenched, but I can't pretend to be on the front lines here.

C# or other language conversion will come one day. Surely.

Pcelba--Thanks for the bottom line:
"C# or other language conversion will come one day. Surely"

Olaf--Thanks fro the upsizing tips. I will pass them on to the fellow looking at the angles.

Note that even if the C#/C++ conversion occurs, you could still utilize the VFP data tables through an ODBC connection.

One of my clients needed a web-centric version of their legacy VFP application so they created a VB.Net version of the application which runs through the browser (not a small task) and which connects to the existing VFP data tables through an ODBC connection (a relatively easy thing to do).
This works perfectly fine -- although most VB.Net or C#/C++ developers might initially balk at that approach.

So unless you are running into the 2GB file size limitation or you should need better data security you should have no current 'burning need' to make the data table conversion to SQL Server.  
Keep in mind that when you make that change, your VFP application (should it still be Active) will need a good number of changes to utilize the data.

Good Luck

Interesting angle. As always many ways to solve a programming issue (won't call it a problem yet!). I will pass this on, but I suspect you are right--this would not be the developer's first choice. But time and cost are certainly an issue.

Good points. As I look at what we have built in, I do see that there is more than the costing--multiple commission rates varying by product, brand, broker and/or customer; expiration date tracking,  general ledger and financials . . . But all this may be out there pre-packaged. The time has come to take a look.