不可以！
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本身上来就，效率并不差的！