摘要： 产生这个问题的原因，其时是由我们的习惯引起的，一般说过，我们的update操作是这样的1 从数据表把数据获出来2 修改取出现的实体值3 发回给数据表，更新成功这看上去没有问题，但在EF环境中就会产生问题，因为当你取实体时，默认情况下EF会向ObjectStateManager提交一种跟踪机制，即向它里面添加了一个键值，而当你调用update时，这时它已经有这个键值了，所有出现异常也很正常。解决方法1：不使用上面的逻辑，直接将实体附加到数据上下文中，这是可以的解决方法2：在获取单条实体时，取消实体跟踪，扩展方法是AsNoTracking()，这时不会向ObjectStateManager添加键值 阅读全文

摘要： 编译器错误消息: 类型“System.Data.Objects.DataClasses.EntityObject”在未被引用的程序集中定义。必须添加对程序集 “System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089” 的引用。原因，因为在进行页面渲染时用到了这个程序集，而程序没有加载这个，所以出现了错误，一般地，我们可以在Web.config中，注册这个程序集如下代码：1 <assemblies>2 <add assembly="System.Web. 阅读全文

摘要： 回到目录上回主要把数据操作规范及EF两种基类下的实现说了一下，今天主要针对ObjectContext情况下的批量操作作一个详细的说明，首先，要说明一点，批量操作不用ObjectContext提供的方法，而是使用拼SQL串的方式，将列表拼成一个SQL串，一次的发给数据库，这样在性能上绝对是一个质的飞越，本人尝试过，无论是EF还是linq to sql，它们提供的方法，对于列表的操作会产生N条SQL串（N＝列表的长度）。一个操作类型枚举：1 /// <summary>2 /// 執行SQL的類型3 /// </summary>4 pu... 阅读全文

摘要： 回到目录在EF环境里，我们的数据上下文对象通常是有两个版本，一个是DbContext对象，另一个是ObjectContext，个人觉得前者是轻量级的，对于code first模式中使用比较多，而后者是原生态的，最初的EDM（entity Data Model)就是以这个为基类的，它的实现与linq to sql很类似，也是分部方法，lambda表达式等元素的产物。看看我的一个规范，两个实现吧！一个规范： 1 namespace Commons.Data 2 { 3 /// <summary> 4 /// data repository interface 5 ... 阅读全文

摘要： 1 <%@ Page Language="C#" %> 2 3 <%@ Import Namespace="System.Data.SqlClient" %> 4 <% 5 string ServerName = "测试"; 6 string DBIP = "-"; //　-　表示没有数据库服务器 7 string DBName = ""; 8 string DBUser = ""; 9 string DBPassword = "&qu 阅读全文