Just wondering about something

There is absolutely no reason not to have them. I have experimented with Linq and tried to use it with a small(ish) project and really wish I had not.

The biggest problem with new things like Linq is that you literally are putting SQL queries in your page (code behind). The way Linq is implemented at present means that you cannot have all your queries in a seperate .dll and have a clean separation of concerns. Datasets/adapters offer a far much cleaner speration of concerns than Linq and the support for them is mature so you get an excellent developer experience.

People always get bored and feel that they should change things in order to progress (new job, make your stamp on things) but stored procedures are still best (in my opinion).

The ADO.NET Entity framework is going to be the next data thing worth looking at, but again, as Microsoft go, you probably will get a 60% complete product and I will wait till VS next version till I use it in a live project. I used to run and jump on the latest technology trends and have paid the bitter price in wasted time, money and productivity, when existing technologies would suffice.

Stick with Stored Procedures! Put you stamp on usability, performance and UI.

I feel that his business logic is already in the best place. Stored procedures are disliked because they are awkward and basically you're using functional programming instead of imperative.

One can use Linq to sprocs you can also use sprocs with table adapters, but you have problem with joins. The unskilled approach is to use correlated queries but JOINS are the best way to perform this as illustrated in this example here.

In windows forms databinding with Linq across two tables to perform aggregate queries requires quite a bit of coding. Lets say, for example, you are using the standard datagridview. With table adapters, you can use your correlated sql query or stored procedure and you get all the fantastic binding that comes with it. You can format your grid easily, because the columns are generated at design time. Try this with Linq joins, the best you have is the autogenerate columns enum. I have an application with several grids and this is a doddle with table adapters.

The biggest problem with Linq to SQL is in N-Tier applications, specifically where you want to use offline data synchronisation services, you find that Linq to SQL Compact is not supported, whereas datasets are made for this scenario. I was elated when I came across this n-tier example http://www.subsonicproject.com/view/soniccast-6---linqtosql.aspx but came across (even the guy in the video has problems) difficulties again. With datasets validation is made for n-tier, you can call .SetSolumnError(thiscolumn, "Linq is not mature yet, stick with sprocs") in your data set project, with Linq you have to throw and then handle the exceptions from the partial classes. Again a real time waster.

I also use third party components and you will find that most if not all grid/reporting/charting components are made for datasets, this is the de facto implementation. The Linq team did not address all the above and more, which is why take up will be slow in the enterprise, regardless of what MS promulgate! Most people that extol Linq either teach it, have dabbled with it, or have written a book on it. NONE of them have ever written an enterprise application with it (yet).