>>I think we all pretty much agreed that the 'gradual migration' that Mike is faced with is *not* a good idea - they will end up spending more time fire-fighting than developing. But, given that his 'powers that be' won't go for a clean rewrite, then AFAICS the options are to:
>>(a) rewrite the VFP code so that it will *temporarily* run against SQL or
>>(b) write a .NET DAL that will *temporarily* run against the VFP data.
>>
>>So, given that both of these efforts will eventually be discarded, it's a question of which is the best option. I favoured the latter on the grounds that it avoids the almost inevitable disruptions that messing with the VFP code can cause. Whilst not pushing it out to other sites it should be possible to work with a hybrid solution on the development site if that's what they want?
>
>I just saw someone recently say they had gotten nHibernate to connect to VFP data so that might be the way I would go if they went the second route. At least then you're not attempting to create what would almost certainly be a pretty ugly DAL and it's one that could be switched over to SQL easily once they're ready. Even then I'm going to assume they're going to have to make all sorts of compromises in their .NET code to get things to work w/VFP as a backend (stuff that will leave their future .NET developers wonder WhyTF they did it "that way" for <g>).

Maybe the .NET developers should set up a hot key to insert a comment line before all such code: "Nothing runs like the Fox" ;-)