John,

>Hi Doug..
>
>Yes, it was Earl Grey! < bg >

Now I am completely comfortable with your thinking process. If you chose Earl Grey then you are of sound mind IMO. <g>

>
>
>IMO, there are two important messages that have to get out:
>
>1. It is just fine nor should there be any worry about using VFP for application
> development today.

Yup. Where the technological requirements warrant. In my particular case that is, in fact, the case.

>
>2. When the VFP developer *IS* ready to make a move or when he is ready to
> contemplate a move, valuable resources and assistance will be there for him.

Yes. Having some 'seminal' resources would be good to have.

>
>Your points about Macro Substitution are important. It is a widely used feature that will not be in .Net. It is a gap that must be bridged. Whether it was/is smart to use Macro Expansion is not the issue. The bottom line, macro expansion is a feature of VFP. Like all features, they are fair game to be used. They key is in creating strategies that bridge the gap.

Exactly. I think in one of your other messages you suggested calling VFP objects/web services from .NET. That is a compelling point IMO. Now, as I had mentioned; in my particular case, since we distribute several hundreds of MB to each and every desktop (and provide ongoing updates via the Internet) continuing to use VFP as the desktop development platform makes sense. Once the Internet gets fast enough to satisfy our particular needs we'll be ready to move everything off the desktop to the net. It's just not the right time at this point.

>
>As far as SQL Server is concerned, there is one other point I forgot to point out. When the next version of SQL Server (YUKON) is released, it will have the ability to host the CLR. What does this mean? It means you can write VB/C# components and host them in SQL Server. This is an important step to modernizing the language of SQL Server. Eventually, you will be able to use the same language across all tiers of an application...

No kidding.. That is a pretty big deal.

>
>As for scaleability and whether SQL can keep up with Oracle, I guess it depends on the scenario. Everything I have read leads me to believe that SQL will scale just fine. My experience leads me to that conclusion as well..

Glad to hear this. In our case we expect eventually to have up to the terrabyte level of data online. What is your personal experience with respect to larger data stores under SQL if I may ask...

Also, what issues O/S-wise have you encountered?