Using linqpad as primary query tool

Question

A member of my team recently moved to LinqPad as his primary query tool (still will use SQL Studio at times) for the simple purpose of forcing himself to make using LINQ more natural to use. I thought this was a pretty good idea and am considering asking the rest of my team to make this switch. Does anyone have any thoughts / ideas on taking this approach?

Early questions I had...

1. I feel being able to write good ANSI SQL is critical for a LOB developer. Since LINQ is a Microsoft thing, is the skills they will learn in LINQ worth the sacrifice in fully developing their ANSI SQL techniques, particularly if (when) they move on to other jobs/duties later in life. Developer development (inside and outside of company) is extremely important to me.

2. Are there any features in SQL Studio that will be sorely missed in LinqPad?

3. Does LinqPad have long term life? In other words, does everyone feel that LinqPad is a product that will continue to grow as .NET and SQL grows?

Answer 1

Are there any features in SQL Studio that will be sorely missed in LinqPad?

Does LinqPad Show Estimated Execution Plan ?

Answer 2

As a way of drilling LINQ into yourself LINQPad is great, and if as a developer you're planning on staying within the Microsoft ecology, then that's probably a good thing.

Yes, there are a number of things you can't do in LINQ that you might need another tool for, whether that's SQL Management Studio or Visual Studio, however as you can drop down to SQL in the language some of these are mitigated if you can remember the SQL for it:

1. Create new tables
2. Modify existing tables
3. Create SQL Agent Jobs
4. Import/Export data

Obviously these are mostly "management" activities.

While LINQPad won't give you the execution plan, it will give you the SQL that is going to be run.