Rick, can you tell me why this "schema change" issue gets applied exclusively to Linq to SQL?

Typed Datasets, Stored Procedures and even the Entities Framework (that for some reason is presented as the golden child in this regard) all need to be updated to match a changed schema as soon as they encounter the change. Uncoupling in the EF does not avoid this problem though it may postpone it.

Could it be because the whole Linq to SQL thing is so automatic and easy than when you hit a hurdle, it comes as a bigger jolt? And I think you might have a point that if too much is hidden inside the shiny shell, you're less in control when things go wrong. But that's also true of a modern car: what matters is how *often* things go wrong. ;-) From what you and Kevin are saying, they go wrong in Linq to SQL quite a lot. So, in the interests of argument I must say that I've seen some really *good* SQL coming out of Linq to SQL, especially if you break things into newbie functions and let Linq to SQL assemble a single uber-SQL. Obviously my "complex" queries aren't as grown-up as yours ;-) so can you provide some examples where Linq to SQL coughs? We might as well figure out what this thing is good for- though it's so accessible and productive that everybody might as well at least look at it.