I've attended as many dotnet events as I possibly could in the last several yrs. Not once, never, has the question of "auto-spanning" ever arisen.

I am working with an accounting app right now. The company is planning to retire the VFP app eventually. And the replacement is written in Java. I've been working with the Java team for the last year.

The Java app is by no means perfect right now. But I can tell you that the app shortcomings are not due to Java, but to developers who didn't really understand what they were doing. The app is in use by a significant number of customers.

It is possible that John R. has a need to massage hugh amounts of data. But the typical business app doesn't have to operate that way. So far he's the only one who's described a scenario where he might be better off sticking with VFP. But I just don't see it from anyone else here.

>Seriously, if you're doing straight data entry/fixed reporting apps, NET works well. But once you start data processing, NET is more limited. Automatic spanning of datasets between memory and disk is one high profile example. Senior MS people have said this is a priority for Linq. Fantastic! It's already begun- the absolute preference for stored procedures is being softened by recognition of SPT and local datasets. The day the dataset matches the VFP cursor in this area I'll agree with you, though I won't boast that I've been saying it for years. ;-)
>
>Overall: IME there's nothing VFP'ers would like better than to know there is a replacement MS tool that matches or exceeds what they're used to. It doesn't mean they'll all troop across obediently, it means there's a recognisable option if they want to stay in the MS stable, as I'd like to.
>
>Hi, John,
>
>Not looking to throw swords back and forth.... ;)
>
>I'll only speak from what I've seen - auto-spanning is not a high-profile (nor even common) topic outside the VFP community. Additionally, I know other VFP/.NET developers who don't feel this is a major issue - certainly not one to justify "waiting to learn .NET" or to characterize ADO.NET as being unfit for data-handling. I've done .NET applications featuring dynamic reporting, heavy data processing, and haven't felt myself in a state of developer tool poverty.
>
>Just to clarify....yes, I've seen a few instances where people needed auto-spanning - in some cases, they WEREN'T allowed to use stored procedures at all. Sure, it'll be great when this capability comes around, but I think this has been an excuse for people to avoid learning .NET altogether.
>
>The .NET 3.0 framework introduces new capabilities that call on the use of .NET generics - which was added to the 2.0 framework and takes time and mental energy to grok. It would have taken me longer to learn WCF had I not previously learned generics. Do you not agree that anyone who waits for a pure genetic match to start looking at the replacement tool, likely does themselves a disservice? Those who didn't wait will are able to learn incrementally, while those who waited are more likely facing a huge challenge. I personally know VFP developers who went off and learned .NET on their own - after a year or two, they were promoted to .NET positions in the same company.
>
>Yes, LINQ will be a great thing on the client side. (Though as an aside, a number of LINQ examples I see can be done today with ADO.NET Dataviews or List FindAll/Sort Predicates.) The majority consensus out there is that stored procedures are still the way to go...(yes, assuming that decent hardware exists...) I just did a mental count: in the last three years I've added at least two major clients each year. ALL were using stored procs before I came along (and that includes VFP installs). Microsoft added a number of features in SQL 2005 to further enhance stored proc development. Stored procs aren't going anywhere. My preference for stored procs isn't "absolute": I use them as a starting point, unless there are strong/critical reasons not to.
>
>Kevin