[Solved]-If using LINQ to SQL is there any good reason to learn SQL queries/syntax anymore?-LINQ,C#

its always a good think to learn the underlying language for stuff like linq to sql. sql is pretty much standardized and it will help you understand a new paradigm in programming.

• you may not always be working in .net.
• doesn't hurt to know the underlying concepts.
• linq to sql is not being maintained anymore in favor of the entity framework

sooner or later you will run into problems that need at leat a working knowledge of sql to solve. and sooner or later you will run into requirements that are best realised in the db (whether in sp-s or in triggers or views or whaterver).

linq to sql will only work with .net. if you happen get another job where you are not working with .net, then you will have to go back to writing stored procs.

knowing sql will also give you a better understanding of how the server operates as well as possibly making you a better database designer.

it is still important to learn sql queries/syntax. the reason is you need to at least understand how linq to sql translate to the database behind the scenes.

this will help you when you find problems, for example something not updating correctly. or a query performance needs to increase.

it is the same that you need to understand what assembly language is and how it eventually becomes machine language. however in all you don't have to be an expert, but at least be able to write in it and understand it.

it is still important to know sql and the paradigm (set-based) behind it to be able to create efficient sql statements, even if your using linqtosql or any other or/m.

there will always be situations where you will want to write the query in native sql because it is not possible to write it in linqtosql / hql / whatever, or linqtosql is just not able to generate a performant query for it.

there will always be situations where you will want to execute an ad-hoc query on a database using native sql, etc...

i think linqtosql (or other linq to sql providers) should not prevent you of knowing sql.

when your query is not returning what you expect, or when it takes 30 minutes to run on the production database, you'd better be able to understand what lts has generated, and why it is failing.

i know, it's a rehashed topic, and it might not be applicable to what you do ("small" database that will never hit that kind of problem etc), but it pays not to get too oblivious of abstraction layers sometimes.

the other reason is, linq does not the whole range of what you can do in sql, so you might have to resort to writing "raw" sql, even if the result is materialised as objects.

it depends what you're working on, and from what you said it might make more sense to focus on other areas.

having said that i find knowing sql allows the following:

• the ability to write queries to extract data from systems easily. for adhoc queries, or for checking things.
• the ability to write complex stored procedures, which allows me to group complex data processing in one place, where it should be, in the database.
• the ability to fine tune linqtosql by adding indexes, and understanding the sql/query plan's it procedures.

most of these are more of a help on more complex systems, so if you're not working on those it might not be as much of a help.

it may help in your situation to list the technologies which might be of use, and then prioritise them.
in order words make a development plan for yourself, which may encompass more then just learning technical knowledge but allow a more broad focus like design patterns, communication skills and other areas.

sql is a tool. linq to sql is also a tool. having more tools in your belt is a good thing. it'll give you more perspectives when attacking a problem.

consider a scenario where you may want to do multiple queries or multiple updates to the db in one operation. if you can write tsql you can potentially save yourself a lot of roundtrips to the database.

i would say you definately need to know your sql in depth, because you need to know what code your linq-expression generates and what effects the code will have if you want high performing queries. sure you might get the job done in most cases, but sometimes there is a huge difference in performance in very subtle difference in linq-syntax.

i ran into this this morning actually, where i had done .any(d => d.id == (...).first().id) instead of doing where (...).any(i => i.id == d.id). this resulted in the query executing five times slower.

sometimes you need to analyze the actual sql-query to realise the mistakes you make.

in my opinion, knowing sql is more valuable than any vendor specific technology. there will always be cases when those nice prepackaged frameworks will not be able to solve a particular situation and knowledge of advanced sql will be required.