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. Whether the source is there or not is inconsequential for most of us. You and I aren't going to change system code. And few others would I think if new technologies come out that improve upon the old mechanism. Just because it doesn't get improved doesn't mean it doesn't work anymore. I still have several LINQ to SQL apps in production that are running just fine and there's no need to upgrade them to anything else.

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.

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 :-)


+++ Rick ---


>But you are still living on the whim of MS to decide when to focus on the next iteration of data access technology,
>leaving your old apps running but getting no more dev love from MS side.
>As the source is often not available when using pure MS tools, you have more problems after that point in time -
>which balances the ease of starting compared to developing your own data access classes.
>
>
>>LINQ to SQL and EF both create SQL statements, and pretty darn good ones.
>>
>>>Neither is SQL ;-) I meant the query method/language as in screwdriver vs. hammer.
>>>
>>>>As for local cursors, there are times when they are useful, but having to pull so much data across the wire to resolve the query is not efficient either.
>>
>
>Call me oldfashioned, but such data belongs onto the disk, even if it is a mSDHC:
>RAM should not be thought of as limitless resource, esp. on mobile platforms.
>
>>You can do this in .Net too.
>>
>>>
>>>Yes, but you can also remember already sent over pages via caching or
>>>cache and query with timestamp info, thereby lessening data transfer.
>>>Rowversion info or atomic timestamps are good ;-)