1. 一个项目中可以有linq to sql 和sqlserver一起吗
linq to sql只是一个技术点，sqlserver是数据库，所有的表和数据得放在数据库里面的，包括你的约束，存储过程，触发器等，linq to sql 是将数据表和数据做一些entites映射，然后你可以做很多操作，比如说查询，删除，增加等封装起来成一个类，这个类要负责和sqlsever通信。这个和你写普通的操作数据库的类得效果一样，但是linq to sql比较安全一点，大量数据操作时性能也好一些。
这是两个概念，你的项目里面必须有数据库的，至于你用不用linq to sql 全取决于你的兴趣。有专门的架构是用linq to sql来完成一个项目的，也可以混用，你可以在网上查查
参考： http://www.bccn.net/Article/sjk/sqlserver/jszl/200709/6578.html
2. 用linq to sql时出现的问题
1、请仔细检查你的字段中是否有自增列。
2、如果是一开始有，DBML中的类型和数据库中的字段类型是否是同步修改的？
如果都不行，那么你重新建一下DBML试试！
3. llinQ语句可以在sql数据库中运行不
不可以！
linq是微软件.net平台上的ORM，也就是说，linq是数据向程序转变的一个中间层，可以将将程序的对象通过linq等ORM转变成合适的语句，存储或修改而持久保存在数据库中，也可以通合适的语句，将数据库中的记录数据转化为程序可用的对象，所以这个中间层被细称为ORM,实际上就是业务逻辑层的细细分而已民。其中对象自动生成，减少了程序开发的周期。
而SQL只使用是ANSI-SQL与Trans-SQL(TSQL)执行数据库操作。并不认识其中间层的ORM，其语句并不能在其中操作，虽然两者看起来很相似。但实际上一个是SQL子句，一个是linq对象方法或称属性。但还是有很大的区别的，外形象但不表示是同一范畴的东西。
比如在SQL中必须使用子句 order by进行排序，且默认情况不区分大小写，而在linq中使用的却是Orderby方法（也可称子句，但些子句非彼子句）,中间不能有空格，且必须是大小写区分的。
等等类似，皆说明两者并非同一范畴。部分语句虽可以执行，并只是表达习惯上的巧合，而并非同一范畴。且，SQL是数据系统中要使用的，其实很多时间linq处理一些较为复杂的事务时，多是力不从心，但毕竟只是.net平台上的一个轻量级ORM，并不能多做苛求！
所以，这里说两者没有任何关系，是不可以的！一个属于框架集（.net平台开发),一个是数据库，不同的东西还能说可以么？
4. 请问.net为什么抛弃了linq to sql EF与linq to sql 相比较，前者有哪些优势
说是抛弃也不太对，因为这部分被合并在Linq to Entity里面了。
ADO.Net Entity Framework 与Linq to SQL的比较和适用场景：
MSDN上最近发表了一篇Elisa Flasko着的文章，比较了LINQ to SQL与LINQ to Entities适用的场景:
Introcing LINQ to Relational Data
http://msdn2.microsoft.com/en-us/library/cc161164.aspx
作者指出，LINQ to SQL主要的应用场景是针对微软SQL Server数据库的快速开发，这些应用的对象模型与数据库中数据定义的结构间非常类似，几乎有一一对应的映射关系，这样你可以使用LINQ to SQL把一些数据表直接映射到.NET类，数据字段映射到的相应的.NET类的属性上。作者总结如下：
LINQ to SQL适用之场景
.想使用ORM方案，而且数据库数据定义与对象模型是1：1对应关系
. 想使用ORM方案，而且对象继承结构储存在单一数据表中（单表继承）
. 想使用原始CLR类，而不是使用生成的类或需要从某个基类继承而来，或者需要实现某个接口
. 想使用LINQ来编写查询
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能
LINQ to Entities主要的应用场景针对的是需要非常灵活和更复杂的映射的场景，特别是在企业应用方面，而且需要访问其他的数据库系统。在这些场景中，数据表的结构与对象模型也许差别很大，而且应用开发人员往往并不拥有生成或修改数据库数据定义的权利。
LINQ to Entities适用之场景 :
.想要开发针对微软SQL Server或其他数据库系统的应用
. 想要定义领域模型，并以之为持久层的基础
. 想要使用ORM方案，对象也许与数据库数据定义有1:1对应关系，也许结构迥异
. 想要使用支持单表继承和其他储存方案（每类一表，每具体类一表）的ORM方案
. 想使用LINQ来编写查询，并且查询可以在不同数据库系统下工作
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能
5. 能把linq中的where里的条件转为sql吗
可以，linq其实也是sql的功能，只是linq和sql的写法不一样，关键字什么的都一样，两个是可以相互转换的。
6. LINQ和LINQ to SQL有区别吗之间关系是什么
LINQ是集成化查询语言，可以用于对集合进行查询。
linq
to
sql是linq的扩展框架，支持linq针对SQL数据库进行查询（将查询的条件转化为SQL语句）
7. LINQ比一般的SQL语句效率更高吗
Linq是一个范围比较大的概念，它其中不单单只有linq to sql，还有相应的linq to xml等等。所以拿linq 与SQL语句相比，没有可比性的。
但如果拿linq to sql相比的话，与SQL还是有很大的可比性的。一般情况下，你必须要明白你所指的效率是哪一方面？是数据库执行效率？还是整体成品软件运行效率？还是开发效率？
开发效率上linq to sql显然要比SQL的效率要高很多，我们使用linq to sql 可以很容易实现编程，其中的代码量也大大减少。所以如果从开发方面linq to sql的效率是毫无疑问要高于直接的SQL与数据库连接。
如果从编方译考虑，这个一般情况下，linq to sql是引入的新的技术，效率肯定是不如SQL的。好在这个编译的部分不需要开发人员或是任何用户的参与，所以即是效率差一点，对软件来说没有任何的影响。
最后一部分你可以比较感兴趣，谁对数据库的连接更快，执行效率更好？答案是linq to sql而不是直接的语句。一般我们使用直接的语句要求的是即是的执行，但事实上很多时间我们根本不需要那么多，linq to sql其实说明了就是会自动生成与表结构同样的一些对象。而这些对象在联系数据库时也是直接编译好的语句，直接联系时，两者效率是相同的。
但是，如果我们对数据进行处理时，你就会发现，linq to sql的效率为什么会更高了！因为他在读取时不但会读取当前表来填充生成的对象，同时还是延时读其相关表，为你使用有关系的表提供了极大的方便。那么你的相关表的读取效率要快了！
但不管怎么样，他们都是在站立在了ado.net的基础之上的，只不过有些自动生成了，根本不需要你再去做而已。唯一效果比较差的是，linq to sql读出的数据在系统中被转化了，同时它效率虽然变差一些，但是却带来了另一个好处，就是我们常说的SQL注入问题不再出现，你所输入的任何东西都会变成了字符串了。
其实ADO.net的方案中我们使用了datareader方案的效高是比较高的，但是对于更新却是极差的。而使用数据适配器的方案效率较底一些，更对于数据的更新是相当好的，而对于linq to sql其实它是使用数据缓存方案，也就是说linq to sql其实将数据库中的数据缓存到了对象中，如果对象发生了更改，有必须过行返馈时，它是可以进行反馈的，而是这种反馈是可控制的，事务性的。从各方面给我们带来了好处。
我们可以在更新了很多内容之后再去提交更改，那么这种效率论从理解上还是效率上都优化你的原来的语句的！所以linq to sql并非在性能上的降低，而是一种提高。
严格说来，linq to sql并不是节省了代码，相反它增加了很多代码，便幸运的是，这些代码都是由linq to sql框架自动生成的。若是换作人工，容易出错的。但在使用时，由于框架完成了大部分的代码，我们再使用linq to sql加上lambad表达式或查询表达式，我们的代码就变得极少且极简洁了！而如果使用lambad表达式或查询表达式时，它的效率显然不如直接SQL来的直接。读取效率会变得差一些的！
这是因为lambda表达式或查询表达式是一个动态编译的效果，而不是直接编译好的，他要对语句进行编译与优化以何证效率，但性能上因为多了一重处理，效率没有SQL来的直接。但一般情况下，使用linq to sql配合查询表达式或lambad表达式时，效率虽然稍差，但是带来的却是代码的简洁与易理解性，如果不配合查询表达式与lambad表达式，linq to sql的优劣还不利用体现。所以关非linq to sql的效率差，而是我们使用了查询表达式的动态编译导致了效率较差。就linq to sql本身上来就，效率并不差的！
8. LinQ 可以取代SQL语句吗
个人认为目前还不可以了因为LINGQ的局限性很大，复杂一点的SQL语句难以用LINGQ编写或编写麻烦。
9. 有了存储过程，linq to sql还有必要用么
这两者比较比较少
首先使用存储过程就是一个有争议的话题，爱使用存储过程的程序员往往会把过多的业务逻辑封装在存储过程里，导致应用程序的可移植性比较差
而且一般会说使用存储过程的性能比较高，但现在由于各种缓存技术的使用，减少频繁的查询数据库已经是共识。
一般而言使用数据库的存储过程居多还是业务逻辑处理居多基本取决于公司的技术方向，我也见到不少公司是忽视软件的开发，基本处理逻辑都是在数据库中解决的。
至于linq to sql，说句老实话谈不上是什么特别好的技术，仅凭仅能使用sql server数据库这一点，就已经限制了它的发展。看看现在多少公司还在用免费的mysql就知道了，更不要说还有那么多的开源产品是建立在mysql之上。而同类的产品Nhibernate绝不会比它差。
10. 弱弱的问一个Linq和数据库sql性能的问题
对的。一个是从数据库拿出所有数据再筛选，一个是直接在数据库查找符合条件的数据，效率当然不一样。LINQ
TO
SQL的确存在性能问题，但是LINQ
TO
XML等其他功能还是很好用的。