对于ef本身是支持事务的，即SaveChanges(),可是使用中发现一个问题，在更新当前对象过程中如果从上下文获取一个其他对象也要更新并保存，则报错DataReader未关闭。如此的话就不能使用SaveChanges()解决问题了，还是要依赖ADO原始的事务处理方式，如下。DbConnection con = ((IObjectContextAdapter)ctx).ObjectContext.Connection;con.Open();using (var tran = con.BeginTransaction()){// 这里才是事务中的代码tran.Commit();}con.Clos

在进行数据持久化的时候，我们会经常用到事务处理。一般情况下，ADO.NET中的事务处理就能够满足我们的需要，但是，ADO.NET中的事务不能同事对多个数据库连接进行原子性的操作；如果在你的业务环境中存在多个数据库、文件写入等操作，同时需要保证数据完整性和一致性的时候，你可以考虑使用.NET提供的分布式事务处理。使用分布式事务处理，需要Windows系统的支持，所以，我们需要将系统的MSDTC服务开启。步骤：管理工具>组件服务；依次展开 控制台根节点>组件服务>计算机>我的电脑；在“我的电脑”节点上右键打开“属性”；在选项卡中勾选“使用本地协调器”，然后点击“确定”按钮，

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=03.应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进

If you are using migrations you should be able to simply modify code based migration to use newsequentialid() as DefaultValueSql.[Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]public override void Up() { CreateTable( "SomeTable", c => new { Id = c.Guid(null

SQL Server2005提供的新函数：NEWSEQUENTIALID()在指定计算机上创建大于先前通过该函数生成的任何 GUID 的 GUID。原来生成新的GUID的方法是newid()，生成的GUID是无序的，在插入索引的时候会导致效率低下，现在NEWSEQUENTIALID()方法能生成有序的GUID，以减少叶级别索引上的页争用。注意：只要在安装了网卡的机器上，使用该函数生成的GUID才能是全世界唯一的，否则只能保证在这台机器上唯一。另外，该函数只能与 uniqueidentifier 类型表列上的 DEFAULT 约束一起使用，例如：CREATE TABLE myTable (Col

首先需要创建表值函数：CREATE FUNCTION GetLevel ( @Id INT )RETURNS @levelT TABLE ( [Level] INT , IdLevel VARCHAR(100) , NameLevel NVARCHAR(200) )AS BEGIN DECLARE @Level INT , @IdLevel VARCHAR(100) , @NameLevel NVARCHAR(200) , @Name NVARCHAR(50)

说明：1.支持多表查询 2. 支持任意排序 3. 不支持表别名 参考了 IF (EXISTS (SELECT *FROM sysobjectsWHERE [id] = OBJECT_ID('usp_PagingLarge')AND xtype = 'P'))DROP PROCEDURE usp_PagingLarge * /GOCREATE PROCEDURE usp_PagingLarge @TableNames VARCHAR(200), --表名，可以是多个表，但不能用别名@PrimaryKey VARCHAR(100), --主键，可以为空，但@Order为空时该值不能为空@Field

大家都知道在sql中查询逗号分隔数据可以使用in语句,但在参数化存储过程语句中这种方法确实行不通,无论在参数数处传递多少逗号字符串都会被认为是一个值.比如ALTER PROCEDURE [dbo].[Admin_GetListByIds] @Ids VARCHAR(1000)AS BEGIN SET NOCOUNT ON SELECT * FROM dbo.[Admin] WHER Id in (@Ids) END 这里查询结果会为空 SELECT * FROM dbo.[Ad

对于多条件查询的存储过程写法很多，但总体上就这样几种：最低级的写法是 declare @SQL varchar(1000)set @sql='select xx from table where ' +@xxexec (@sql)--或者CREATE PROC PORC_QUERY@WHERE VARCHAR(50)AS EXEC('SELECT * FROM TB WHERE '+@WHERE) 这样的在调用时候会存在一个问题，如果查询条件为空，可就出错了。所以有人使用下面的方式 create proc proc_c@var varchar(50)as begindeclare @sql v

大家都知道在ASP网站时代，都会习惯性的引入一个输入字符过滤的类库，以求程序防止被入侵。可是到了ASP.Net时代，好像普遍对SQL防注入方面的关注度降低了。当然一方面是ASP.Net有众多的数据操作方式，提高了安全性；另一方面可能是因为现在是一个追求效率的时代，以出产品为要，安全性自然被轻视了。近来又在考虑SQL查询的安全性问题，究竟怎么做才能提高查询的安全性呢？可能最有效的解决方式就是SQL语句参数化执行，除了字符串过滤之外，这也是唯一的终极解决方法。关于Like使用的规范化可能一般人对like参数话调用的方式也无非于此 // 用户登录 string sqlStr="select * f