>>>>>>Strongly-type datasets do 90% of that, plus they give you Intellisense on the columns in the datatables.
>>>>>
>>>>>I'm frankly puzzled about this one. As much as I love (and would love) to have intellisense on everything that resides in the database, to "strongly type" datasets assumes that you duplicate your datadictionary in your code no? Doesn't that increase coupling between two components (compiled code and data in the database) that we have worked very hard to de-couple?
>>>>
>>>>You have to regenerate the typed datasets after schema change. So yes, it increases coupling - but that is offset by speed enhancement and intellisense. Other parts of the code are not affected DIFFERENTLY - even using non-typed DS you would probaly would have changes if altering a field name or switching datatype from date to string unless you have very forgiving controls allowing and self-switching on datasource type.
>>>
>>>Yes I understand. But still intellisense is not there when you most need it right, when you are writing an SQL (it wasn't there in VFP either and missed as dearly), so all this strongly typed dataset business does not make a hell of a lot of (intelli)sense to me.
>>
>>I think the idea is that you're not supposed to be writing SQL with the ORM tools available these days.
>
>According to an article by Julie Lerman in MSDN Magazine last year, the ORM tools can generate some horribly inefficient SQL. I don't know whether that's true or how frequently it happens but that's what she wrote.

That is absolutely true with any ORM. It's important to profile all queries during development. Most ORMs have techniques you can use to optimize the queries - lazy loading, eager loading, batching, etc. Not profiling your queries can be dangerous.