>>>>>>>We are planning to rewrite a VFP application which uses DBFs to .NET and SQL Server. The system is extremely large and is comprised of a large number of subsystems invoked from a main PRG and menu. It is not considered feasible to convert everything at once. Instead the plan is to rewrite a piece at a time as resources and budget become available. Has anyone done something like this? To me it seems like the data is going to have to reside in both VFP and SQL Server until everything is converted. Any tips on good ways to do that?
>>>>>>>
>>>>>>>Rewriting a piece at a time can be difficult, if the existing application is also evolving.
>>>>>>>
>>>>>>>Has the team defined segments/timelines for each piece and what will be included? What kind of timeline are you talking about?
>>>>>>>
>>>>>>>Do you have a dedicated QA team? They can be a big help during the transition phase... (just a more general question, what's the size of the team)
>>>>>>
>>>>>>Thanks for the advice. Most of that is not within my control. For at least a couple of reasons the decision was made (above my level) that we can only do it a piece at a time. I have been asked for advice on the data migration strategy so that is what I am concerned with.
>>>>>
>>>>>My advice : resign now. If the aim is to migrate piecemeal from a purely VFP app to a .NET/SQL implementation then all you end up with (if you are lucky) is a pigs-ear .NET application emulating how it was done in VFP. Even without knowing the ins-and-outs of the application involved I'm sure that, in the end, it would be far more efficient (and result in a better application) to start the .NET effort from scratch.
>>>>>My 2c
>>>>
>>>>The sub-applications correspond pretty well to the business activities that are performed here, so in that sense a modular conversion makes sense. The objective is not to change the functionality, it's to get away from VFP and DBFs. The backdrop is that I was brought in as a contractor at a small local company that was acquired by a very large company in May. One of the main reasons they bought the company is they believe the acquired company had some sophisticated software algorithms that will provide a cost advantage against competitors. They have similar operations around the country and want the rewrite here to be rolled out to other locations, maybe all of them. They just don't have any intention of rolling a VFP/DBF application around the country.
>>>>
>>>>I don't think anyone has a line by line translation in mind. There are always things that can be done better the second time.
>>>
>>>Looking through other posts on this thread it seems to me that pretty much everyone thinks a re-write without touching the existing VFP would be the most effiicent and least disruptive option. If that is not a choice there's one other possible approach:
>>>
>>>Rather than initially converting the existing VFP application to run against a SQL back end write a .NET DAL that will run against the existing VFP DBC/DBF's. That way there should be no (or very little) possibility of disrupting the existing VFP operation whereas there would be a very real chance of that happening in the course of converting VFP to use a SQL back end.
>>>
>>>Develop the SQL Database structure and the .NET SQL DAL at the same time. Optimize everything for SQL even if that means more work on the VFP DAL. When the code conversion is complete migrate the data from VFP to SQL and turn of the VFP app.
>>>
>>>Of course the downside of this is that you're stuck with VFP as the prime datasource until the conversion is completed.
>>>
>>>I assume that, IAC, they are not intending to roll this out to other sites until the VFP application is completely redundant ?
>>
>>No one has said that explicitly to me but that's certainly the way it looks.
>>
>>This .NET SQL DAL -- how does that work? I did not know .NET could access VFP data. OLEDB?
>
>Mike, there have been a lot of threads here over the past couple of years (maybe more) on that. I don't have search capabilities here, but you can also look here:
>http://msdn.microsoft.com/en-us/library/3haz2895%28VS.80%29.aspx
>http://social.msdn.microsoft.com/Forums/en/visualfoxprogeneral/thread/9daee6d1-b3a1-40ee-b791-bfe82ac4fc5a
>http://www.foxite.com/archives/idx-vfpoledb-execscript-parameters-0000224626.htm
>http://social.msdn.microsoft.com/Forums/en/visualfoxprogeneral/thread/770c9e5a-8c42-4cdb-bfbb-6894d80c12b3
>
>I like Viv's idea the best myself (given your limited options). Think of a switch that you set which determines which data access to use: sql server or vfp. Twice the coding, but I've worked on many apps that were designed that way in VFP as well and the vfp and .net modules can work side by side in the process. More options with .net actually in how to do it. When the entire vfp app is no longer needed, as Viv said, just move the tables to sql server and change the setting to the sql backend option.

Since they don't plan to roll this out anywhere else until the .net thing is done I don't see what it buys you to have any real data CRUD being done in .net while it is still under development. Leave the VFP app as it is, run your conversion regularly to sql, develop .net against that As you find it a good idea to adjust the schema in sql, adjust the conversion program to suit. When .net is finished, you run the conversion a final time and shut down the vfp (though you could even run them parallel for a month or so to doublecheck the results)