> As for not getting paid, are you not at work right now??????

Uh...lunch hour? Break between writing .NET-related tests?

>So, as a MS person, you are basically on the record here:

Well, it's actually just my opinion and MS has nothing to do with it, but I know I'll never get off the hook that easily. <g>

>Monolithic/Traditional Apps - VFP is the way to go
>C/S, COM, Web, etc - Other tools may be better suited for the task. Or as you said, all bets are off....

That would accurate, yes, if we replace "tools" with "tools/technologies". I believe that going beyond traditional apps, VFP can still be a good stand-alone tool choice, or when used with the appropriate technologies. Semantics, yes, but as you've pinned me as the unofficial MS spokesman in this thread, I want to make sure I'm not misunderstood. <g>

>I can tell you this - between a monolithic app and the decsion as to whether
>you upsize to SQL - there are hundreds of miles. For starters, it cannot be
>done without a rewrite. Anybody who has tried, has failed. Why? For starters,
>they relied on Remote Views. They found out the hard way that RV's don't work.

To me, the main issue is something you pointed out earlier: using stored procs for everything for the reasons you listed. I doubt very many developers have done that in their traditional apps. I don't know, maybe I'm out of touch, but I'm guessing there's a lot of USE/REPLACE out there. Based on conversations with customers from when I was working support, if written from the beginning with eventual upsizing being kept in mind, I think it would go fairly smoothly.

>And, if you are going to resort to a rewrite, you owe it to yourself, to your
>client, to the app to re-evaluate your toolset.

I couldn't agree more. That being said, I personally don't have much use for VB, as a "for instance". "Because VB is a bad tool?" No, not at all. I just don't have much need for another drag-and-drop, high level development tool. If I can't get what I need done in VFP, I'll fire up VC++ and write a COM DLL or ActiveX control to do it. So I don't see anything wrong with VFP developers being biased toward VFP when it comes time to rewrite and to reevaluate their core toolset. There's something to be said for leveraging what you know, instead of jumping willy-nilly to "the next big thing". At the same time, the developer should at least to be aware of the options, and not isolate themselves because of their biases.

>I must say, it is very refreshing to dialog with a MS person on this topic.

It's always good to get an idea of what those outside Microsoft are thinking. That's why I hang out on the UT, even if it's not in my job description.

>Why do I get the feeling that several hundred pairs of eyes are lurking on this thread......< bg >.....

Oh, believe me, with that word "Microsoft" hanging off the end of my name, I'm more than aware of it. <g>