>Agreed, but I don't think this is a problem exclusively for Microsoft. Data technologies shift constantly and for all languages. Look at the current NoSql trend and even more so look at tools and frameworks built on top of it. And before that Ruby on Rails vs. ActiveRecord a few years before that. Everything is moving and shifting.

Survival of the fittest will only benefit if there is a plentitude to compete with - all for that.
My main beef is that Source is often not included, when given from "big houses"

>Whether the source is there or not is inconsequential for most of us. You and I aren't going to change system code.

Not to a large degree, but for certain to an analogue of adding a few lines to read out a different table header for .dbf
and correct the differences. Or to fix an error if it is really pressing and evident.

>And while I agree that Microsoft has been doing this a lot over the years and in dumb ass ways to piss off developers and actively drive them to other platforms, I also think that they finally are getting to their original vision for data access (ObjectSpaces) with Entity Framework and LINQ where one set of APIS (LINQ) controls many different data stores fairly uniformly. For a while we'll be safe from major changes, I think. And for once it feels like Microsoft is actually doing the right thing for many of their platforms - especially the Web stuff and also for Data.

I already said that with a lot of new MS things you cannot predict failure before start ;-)
Sure hope that they will refrain from dumb changes for a while -
they will not get chances for too many blunders without some successes in mobile and/or web any more...

>FWIW, even if LINQ (or whatever abstraction) is not for you, for all frameworks that have come from Microsoft there's always been the option to fallback to raw ADO.NET or building a small abstraction layer that provides access to native behavior from the higher level framework. Every 'business object layer' I've built around MS technologies includes the same basic interface plus low level features to fall back to native queries when needed so I can always choose my poison :-)

Worked often along the same lines and think the way the basic APIs are structured withstood the test of time quite well.
Here my main beef is the reliance of living in memory and no local persistance/caching.
The vision for LINQ is ambitious and good - not so sure reversing SQL for it was reeeeally neccessary.

regards

thomas