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


>>>Yeah, that seemed to be the next natural question and I thought of asking him that. But Ken has been hammered so much lately I layed off. I probably wouldn't have understood the technical reason behind it anyways. :)
>>
>>Dean,
>>When anyone rolls out a bunch of "technical" reasons why something cannot be done it is virtually always FUD designed to put the receiver "in his place".
>>The truth of the matter is that anything can be done - it's a simple matter of programming. Trouble is, one has to WANT to DO it.
>>
>>Seems it's easier to tell customers that their wants are mis-informed and technically not feasible than to just go ahead and deliver what the customer wants!
>
>Hi Jim.
>You may be right... in a very cynical way .... ;)
>
>That's what I tell my clients if I don't want to do what they want. Or I tell them that they wouldn't be able to afford it. ~s
>
>
>No seriously. It seems odd that MS would bring VFP this far to just drop it. They must have some kind of long range plans for VFP. I don't believe VFP is going away anytime soon. The VFP jobs may go away, but not VFP.
>
>Anyways, I'm sure others with stronger minds than mine have thought about this before.