Isn't it possible you're only seeing what you want to see? Aren't you assuming an awful lot by thinking .NET is the end all and be all for MS developers? I myself hate following the masses into some predetermined marketing route from Microsoft. VFP can be extremely flexible and I like proving people wrong about it. It's not perfect but what really is??

>John,
>
>Your post is a poster-boy for the problem here. Much like in politics where people obviously only here what they want to hear. Typically, whatever supports what they already believe.
>
>I have had plenty of discussions with my VB/.Net friends and Java co-workers. Guess What??????? Cursors are absolutely, positively, matter-of-factly No Big Whoop to them.
>
>Everyone here continuously harps on the believe that MS killed Foxpro. I just don't think they are seeing reality. I just don't believe that there are that many places that switched from VFP because MS told them too. Lots of these companies wanted to switch to get other benefits.
>
>Also, I think the number of people who were getting ready to build a new product from scratch and potentially using VFP began a substantial shrink within the last 10 years.
>
>From a software developer point-of-view, such as where you are coming from, by using VFP instead of more modern tools, I would worry that features would be introduced in the more modern tool that would never make an appearence in VFP. If your competition makes use of these tools, you could be behind the 8ball.
>
>>Rick,
>>
>>What makes a FP cursor special is its automatic memory/disk spanning. Whether people like it or not,
>>
>>

use mylookup order myorder

>>
>>offers a smorgasbord of options for very little risk or cost. It isn't the VFP syntax that delivers the benefit but the automatic memory/disk spanning. For a start, it allows efficient 500,000 row static lookups at app end or middle tier with no network cycles or SQL load. While this is well understood in VFP, I agree there are legions of developers out there for whom such local data stores would be seen as unpredictable local memory hogs, best avoided in favor of Server-side processing. Well, in VFP you can go either way. I don't want to lose that.
>>
>>i see that some of the Python-spawned languages are starting to offer memory/disk spanning. That's smart. Hopefully that is what MSFT means by a "local data engine" as well.
>>
>>To be clear: this isn't about "VFP is best". It is about improvements to MSFT's designated successor language- improvements that may well be enjoyed by other developers who may have seen a role for a local repository but decided it must be bad design. To me it feels a bit like the belief that diesel engines are noisy, smelly things for trucks, not luxury passenger vehicles. It doesn't have to be that way.
>>
>>Regards
>>
>>j.R