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等其他功能還是很好用的。