>Hi Mike,
>>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?
>>
>Coming in late - yupp, been there, done that.
>
>0)
>Assuming from some read posts you don't have a too favorable attitude to the app -
>don't jump too early to the conclusion that it was a judgement error on the dev part.
>There is quite a chance that some of the pecularities are reactions or adaptations to requests from managment...
>
>0.5)
>For my taste you have not tried to classify the app into categories/parts well or lousy done. I find it hard to believe
>that another company has such high hopes for an app you consider a total washout... Argue with yourself and make bullet lists
>on the app to check against. This makes it easy to identify more/other parts you need to "break out" of the quagmire and get proficient in.
>
>1)
>Get a prioritized list of targets/ wishes for the dotnet conversion and the same for the reasons responsible for the decision reached on the direction/process of porting - especially if you have no say in it. See if cutting out GUI from other code is needed as a discrete step. If so, start ASAP on that ;-)
>
>2)
>work it in 3 steps:
>a) port to using CA while still using dbf - first as a wrapper for all xBase calls including table open and index.
>While you still have the same functionality after semi-mindless replace, this gives you a great place to hook into your log fwk and go from there to SQL conversion without mindless calls to select * killing perf for large sets.
>
>b) port to SQL- backend of your choice. Check out Advantage - might make huge sense in same edge cases if specific locks or discrete adressing of records is needed by the app (very small chance, but keep it in mind) or a possibility for easier porting through a period of access via fox and advantage.
>
>c) port the rest - a simple GUI port won't take long at that point. Moving biz code over fills the time between change calls... New things always done in the ported code.
>

Thank you for the advice. More food for thought.

I must have been in a grumpy mood to have given you the impression I consider the current app "a total washout." It is certainly idiosyncratic in places but it does an awful lot. I still know relatively little of it so it would be premature of me to make blanket judgments of any type.