不可以！
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平台開發),一個是資料庫，不同的東西還能說可以么？
❷ c# LINq實現SQL
varresult=fromarrinsite_jwserver
grouparrbyarr.s_ipintog
selectnew
{
cont=g.Count(),
s_ip=g.Key
};
foreach(varvinresult)
//v.cont
//v.s_ip
❸ 如何查看LINQ執行的SQL語句
如何查看某個用戶執行過的sql語句
--SYS窗口
SQL> select sql_text from v$sql where parsing_schema_name='SCOTT'
2 order by last_load_time desc;
no rows selected
SQL> /
SQL_TEXT
-------------------------------------------------------------------------------
select * from dept
SQL>
--SCOTT窗口
SQL> show user
USER is "SCOTT"
SQL> select * from dept;
DEPTNO DNAME LOC
❹ linq to sql 的執行效率問題
linq開發效率高，寫出的代碼看著舒服，而且在編譯時就可以查出錯誤，如果有語法錯誤編譯是不會通過的，這樣後期維護起來就方便多了。你可以想想，如果是ADO.NET，不用存儲過程話，把sql語句全都寫在代碼里，在編譯時你是看不出錯誤的，只有運行起來以後慢慢調試才知道sql語句有沒有寫錯，或者先把sql語句放到資料庫里跑一遍再寫進程序里，但開發效率都很低。時間就是成本啊，現在的開發越來越講究開發效率和可維護性了，歷史證明為此犧牲執行效率是值得的，畢竟硬體也一直再發展。否則都用匯編寫代碼執行效率肯定最高的。
❺ 如何直接執行SQL語句
1、ExecuteQuery方法
看命名，我們很容易聯想到ADO.NET里熟悉的Command的ExecuteNonQuery方法，但是VS的智能提示告訴我們這個方法返回的是一個泛型集合，應該「所思非所得」。下面通過一個簡單方法，驗證我們的猜想（資料庫設計可以參考這一篇）：
/// <summary>
/// 直接執行sql語句，獲取總人數
/// </summary>
/// <returns></returns>
publicint GetTotalCount()
{
string strSql = "SELECT COUNT(0) FROM Person(NOLOCK)";
var query = dataContext.ExecuteQuery<int>(strSql);
int result = query.First<int>();
Console.WriteLine();
Console.WriteLine("total count:{0}", result);
return result;
}
調試的時候，通過IntelliTrace跟蹤到：
毫無疑問，上面的圖片說明最初的想法是不正確的,」ADO.NET:執行Reader…」雲雲，讓我們更加堅信它實際執行的應該是ExecuteReader方法。當然最簡單的方法是直接查看它的方法說明：
// 摘要:
// 直接對資料庫執行 SQL 查詢並返回對象。
//
// 參數:
// query:
// 要執行的 SQL 查詢。
//
// parameters:
// 要傳遞給命令的參數數組。注意下面的行為：如果數組中的對象的數目小於命令字元串中已標識的最大數，
則會引發異常。如果數組包含未在命令字元串中引用的對象，則不會引發異常。如果某參數為
// null，則該參數會轉換為 DBNull.Value。
//
// 類型參數:
// TResult:
// 返回的集合中的元素的類型。
//
// 返回結果:
// 由查詢返回的對象的集合。
public IEnumerable<TResult> ExecuteQuery<TResult>(string query, paramsobject[] parameters);
ExecuteQuery方法還有一個非泛型方法：
//
// 摘要:
// 直接對資料庫執行 SQL 查詢。
//
// 參數:
// elementType:
//
要返回的 System.Collections.Generic.IEnumerable<T>
的類型。使查詢結果中的列與對象中的欄位或屬性相匹配的演算法如下所示：如果欄位或屬性映射到特定列名稱，則結果集中應包含該列名稱。如果未映射欄位或屬性，則結果集中應包含其名稱與該欄位或屬性相同的列。通過先查找區分大小寫的匹配來執行比較。如果未找到匹配項，則會繼續搜索不區分大小寫的匹配項。如果同時滿足下列所有條件，則該查詢應當返回（除延遲載入的對象外的）對象的所有跟蹤的欄位和屬性：T
// 是由 System.Data.Linq.DataContext 顯式跟蹤的實體。
System.Data.Linq.DataContext.ObjectTrackingEnabled
// 為 true。實體具有主鍵。否則會引發異常。
//
// query:
// 要執行的 SQL 查詢。
//
// parameters:
// 要傳遞給命令的參數數組。注意下面的行為：如果數組中的對象的數目小於命令字元串中已標識的最大數，
則會引發異常。如果數組包含未在命令字元串中引用的對象，則不會引發異常。如果某參數為
// null，則該參數會轉換為 DBNull.Value。
//
// 返回結果:
// 由查詢返回的對象的 System.Collections.Generic.IEnumerable<T> 集合。
public IEnumerable ExecuteQuery(Type elementType, string query, paramsobject[] parameters);
看它的參數需要多傳遞一個elementType，明顯不如泛型方法簡潔。
2、ExecuteCommand方法
同樣道理，這個方法立刻讓我們聯想到（世界沒有聯想，生活將會怎樣？），聯想到，等等，不知聯想到什麼。然後我們看一下方法使用說明：
//
// 摘要:
// 直接對資料庫執行 SQL 命令。
//
// 參數:
// command:
// 要執行的 SQL 命令。
//
// parameters:
// 要傳遞給命令的參數數組。注意下面的行為：如果數組中的對象的數目小於命令字元串中已標識的最大數，
則會引發異常。如果數組包含未在命令字元串中引用的對象，則不會引發異常。如果任一參數為
// null，則該參數會轉換為 DBNull.Value。
//
// 返回結果:
// 一個 int，表示所執行命令修改的行數。
publicint ExecuteCommand(string command, paramsobject[] parameters);
到這里，看它的返回類型為int，表示執行命令修改的行數，這次很容易想到ExecuteNonQuery方法。對不對呢？通過下面的代碼證明我們的設想：
/// <summary>
/// 直接執行sql語句 根據用戶Id更新體重
/// </summary>
/// <param name="id">用戶Id</param>
/// <param name="destWeight">更新後的體重</param>
/// <returns></returns>
publicint ModifyWeightById(int id, double destWeight)
{
string strSql = string.Format("UPDATE Person SET Weight={0} WHERE Id={1}", destWeight, id);
int result = dataContext.ExecuteCommand(strSql);
Console.WriteLine();
Console.WriteLine("affect num:{0}", result);
return result;
}
調試過程中，通過IntelliTrace可以很清楚地捕獲：「ADO.NET:執行NonQuery…」基本可以斷言我們的設想是正確的。
3、防止sql注入
1和2中，執行sql語句的兩個方法都有一個params 類型的參數，我們又會想到ADO.NET非常重要的sql語句的參數化防止sql注入問題。下面通過一個方法，看看linq2sql可不可以防止sql注入。
（1）、直接執行拼接的sql語句（有風險）
/// <summary>
/// 直接執行sql語句 根據用戶Id更新FirstName
/// </summary>
/// <param name="id">用戶Id</param>
/// <param name="destName">更新後的FirstName</param>
/// <returns></returns>
publicint ModifyNameById(int id, string destName)
{
string strSql = string.Format("UPDATE Person SET FirstName='{0}' WHERE Id={1}", destName, id);
//這么拼接有風險
int result = dataContext.ExecuteCommand(strSql);
Console.WriteLine();
Console.WriteLine("affect num:{0}", result);
return result;
}
然後，在客戶端這樣調用這個方法：
int result = ServiceFactory.CreatePersonService().ModifyNameById(10, "'Anders'");
//更新id為10的人的FirstName
❻ linq to entities 中怎麼使用sql語句 請寫個例子我看看，仔細點，我是菜鳥
linq to entities 是不推薦直接執行SQL語句的........
硬要作的話
using (TestEntities ent = new TestEntities())
{
System.Data.EntityClient.EntityConnection con = (System.Data.EntityClient.EntityConnection)ent.Connection;
System.Data.SqlClient.SqlConnection sqlCon = (System.Data.SqlClient.SqlConnection)con.StoreConnection;
System.Data.SqlClient.SqlCommand cmd = sqlCon.CreateCommand();
cmd.CommandText = "UPDATE [Test] SET Value = 'NewValue' WHERE Id = 4";
con.Open();
cmd.ExecuteNonQuery();
con.Close();
}
只能這樣曲線救國了
❼ LINQ更新：找不到行或行已更改
產生此異常，主要是Linq緩存數據和實際資料庫數據不一致的情況造成。解決次問題的情況，主要有幾種：
1.比較簡單的方法，不使用Linq提供的SubmitChanges()方式提交更改，而直接執行SQL語句，例如：
db.ExecuteCommand("Update [dbo].[LinqTest] SET Age=25 Where ID = @p0", 1);
這樣雖然比較方便，但是感覺又回到了直接寫SQL的時代，畢竟Linq to SQL的目的，就是為了讓我們看不見SQL，避免寫復雜的SQL語句，而直接操作實體對象，這樣也可以避免程序可讀性差、不便於維護。所以除非萬不得已，還是不太推薦使用此方法。
2.參考MSDN的資料，採用Linq提供的解決更新沖突的方法，在異常中捕獲沖突，然後手動解決沖突：
try
{
db.SubmitChanges(System.Data.Linq.ConflictMode.ContinueOnConflict);
}
catch (System.Data.Linq.ChangeConflictException ex)
{
foreach (System.Data.Linq.ObjectChangeConflict occ in db.ChangeConflicts)
{
//以下是解決沖突的三種方法，選一種即可
// 使用當前資料庫中的值，覆蓋Linq緩存中實體對象的值
occ.Resolve(System.Data.Linq.RefreshMode.OverwriteCurrentValues);
// 使用Linq緩存中實體對象的值，覆蓋當前資料庫中的值
occ.Resolve(System.Data.Linq.RefreshMode.KeepCurrentValues);
// 只更新實體對象中改變的欄位的值，其他的保留不變
occ.Resolve(System.Data.Linq.RefreshMode.KeepChanges);
}
// 這個地方要注意，Catch方法中，我們前面只是指明了怎樣來解決沖突，這個地方還需要再次提交更新，這樣的話，值 //才會提交到資料庫。
db.SubmitChanges();
}
❽ .net4.0中怎麼使用LINQ與SQL結合。
使用linq的這個方法 ExecuteCommand()
//
// 摘要:
// 直接對資料庫執行 SQL 命令。
//
// 參數:
// command:
// 要執行的 SQL 命令。
//
// parameters:
// 要傳遞給命令的參數數組。注意下面的行為：如果數組中的對象的數目小於命令字元串中已標識的最大數，
則會引發異常。如果數組包含未在命令字元串中引用的對象，則不會引發異常。如果任一參數為
// null，則該參數會轉換為 DBNull.Value。
//
// 返回結果:
// 一個 int，表示所執行命令修改的行數。
public int ExecuteCommand(string command, params object[] parameters)
❾ c#.net用linq的問題
後面接ToList<想返回的類型>，當然如果select語句選的內容不能轉換就會在運行時報錯。
❿ 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本身上來就，效率並不差的！