Oh my God . . . am I about to defend MS? I shudder at the thought, however I do think that it's kind of unreasonable to expect MS to put VFP into .NET without making it conform to how the other members of .NET operate. They have settled on a data access technology and it's going to be a maintenance/testing/training headache to have multiple data access technologies in the product. And if they did it, would only VFP be able to take advantage of it or should they allow you to get at VFP data natively from C#, VB, etc? Doesn't it seem that they would want to limit the data access technologies? They have to draw the line somewhere. It seems the .NET programmers are going to want a good, consistent way to access data and if you start doing the "you can do it this way or that way or this other way" you're just going to muddy the waters. Could they do it? For sure, and it would be great for VFP's standing, but I'm not sure it's reasonable to expect them to. And is it possible the decision is partly due to an anti-VFP bias? For sure on that one, too. They raided its technology for use in other areas, but still they "dis" it all the time because it wasn't invented there. I'm talking about the bigwigs, of course. The VFP team has always done great things for us (though there are some bugs they need to stop ignoring and get fixed). Just my $0.02, Jim. I always enjoy reading your posts.

>Dean,
>
>I think VFP is here for a darned good while yet!
>
>I was referring to its prospects within .NET. MS doesn't want to do it. Period!
>
>That's their prerogative... we just don't need all the bull attendant with the decision!
>
>[Imagine dBASE back in DOS time... DOS has no database so you would lose everything about DOS if you made a database application. That didn't hold water then (I'm sure no one even tried) so why does '.NET does data differently so you'd lose everything about VFP if you put it in .NET'? The ONLY reason is that MS doesn't care to program a .NET version of VFP with local data access.
>
>
>cheers