最近一直被部署后的Web系统一些莫名其妙的随机性错误困扰。 错误有： 服务器无法继续执行该事务。说明: 5e00000094。 ExecuteReader 要求已打开且可用的 Connection。连接的当前状态为打开。 ExecuteNonQuery 要求已打开且可用的 Connection。连接的当前状态为已关闭。 而且出错的地方是最普通的EF方法调用。例如： return db.TB_Article.FirstOrDefault(c => c.id == id); 在通常使用SQLConnection的时候，习惯性加上using语句，控制资源的释放。 using (SqlConnection conn = new SqlConnection()) { //数据库操作 } 而在操作EntityFramework的ObjectContext对象时，也使用了using控制语句（未使用延迟加载功能），以保证资源的快速释放。 using (SDWebEntities db = new SDWebEntities(DbContext.Conn)) { return db.TB_Article.FirstOrDefault(c => c.id == id); } 然而忽略了一个问题，DbContext.Conn属性，该属性是一个EntityConnection对象，并且以静态方式进行存储值。当在using语句的作用范围结束后，同时也会被Dispost掉，造成对象“失常”。 所以采用的方式最好是使用EntityConnectionString连接字符串。 using (SDWebEntities db = new SDWebEntities(DbContext.EntityConnectionString)) { return db.TB_ArticleType.FirstOrDefault(c => c.id == id); } static String BuildEntityConnectionString(string connectionStringName) { string connString = BuildConnectionString(connectionStringName); EntityConnectionStringBuilder entityBuilder = new EntityConnectionStringBuilder(); entityBuilder.Provider = ”System.Data.SqlClient”;//connString.ProviderName; entityBuilder.ProviderConnectionString = connString; entityBuilder.Metadata = @”res://*/SDWeb.csdl|res://*/SDWeb.ssdl|res://*/SDWeb.msl”; return entityBuilder.ToString(); …
machinekey生成、使用方法
MachineKey生成方法 打开以下网址：http://www.aspnetresources.com/tools/keycreator.aspx 点击：Generated 生成的Machinekey: MachineKey <machineKey validationKey=”86B6275BA31D3D713E41388692FCA68F7D20269411345AA1C17A7386DACC9C46E7CE5F97F556F3CF0A07159659E2706B77731779D2DA4B53BC47BFFD4FD48A54″ decryptionKey=”9421E53E196BB56DB11B9C25197A2AD470638EFBC604AC74CD29DBBCF79D6046″ validation=”SHA1″ decryption=”AES” /> MachineKey的使用方法： 将MachineKey添加至Web.config文件的<system.web></system.web>之间 MachineKey的作用： ASP.net 使用 forms authentication 时的 cookie 数据的加密和解密。以确保这部分数据不会被篡改 viewstate 数据的加密和解密。以确保这部分数据不会被篡改。 使用进程外session（out-of-process session）时，对会话状态标识进行验证。 更多详细信息请参考： http://msdn.microsoft.com/zh-cn/library/ms998288(en-us).aspx
MSSQL分组分页存储过程
今天要用到分组分页，这个还不错，就顺势把它拿下，增加了一个返回集合，输出：总页数，总记录数，页数索引，分页大小 /****** Object: StoredProcedure [dbo].[sp_TablePaginationSearch] Script Date: 01/10/2012 23:38:23 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE [dbo].[sp_TablePaginationSearch] ( @SelectField NVARCHAR(512) = ‘*’ — Select语句字段,调用的时候不要输入”select” , @FormTables NVARCHAR(512) — Form子句，表名,包括架构名，调用的时候不要输入”from” , @WhereField NVARCHAR(512) = NULL — Where语句、判断字段，调用的时候不要输入”where” …
SQL Server 索引结构及其使用（四）[转]
聚集索引的重要性和如何选择聚集索引 在上一节的标题中，笔者写的是：实现小数据量和海量数据的通用分页显示存储过程。这是因为在将本存储过程应用于“办公自动化”系统的实践中时，笔者发现这第三种存储过程在小数据量的情况下，有如下现象： 1、分页速度一般维持在1秒和3秒之间。 2、在查询最后一页时，速度一般为5秒至8秒，哪怕分页总数只有3页或30万页。 虽然在超大容量情况下，这个分页的实现过程是很快的，但在分前几页时，这个1－3秒的速度比起第一种甚至没有经过优化的分页方法速度还要慢，借用户的话说就是“还没有ACCESS数据库速度快”，这个认识足以导致用户放弃使用您开发的系统。 笔者就此分析了一下，原来产生这种现象的症结是如此的简单，但又如此的重要：排序的字段不是聚集索引！ 本篇文章的题目是：“查询优化及分页算法方案”。笔者只所以把“查询优化”和“分页算法”这两个联系不是很大的论题放在一起，就是因为二者都需要一个非常重要的东西――聚集索引。 在前面的讨论中我们已经提到了，聚集索引有两个最大的优势： 1、以最快的速度缩小查询范围。 2、以最快的速度进行字段排序。 第1条多用在查询优化时，而第2条多用在进行分页时的数据排序。 而聚集索引在每个表内又只能建立一个，这使得聚集索引显得更加的重要。聚集索引的挑选可以说是实现“查询优化”和“高效分页”的最关键因素。 但要既使聚集索引列既符合查询列的需要，又符合排序列的需要，这通常是一个矛盾。笔者前面“索引”的讨论中，将fariqi，即用户发文日期作为了聚集索引的起始列，日期的精确度为“日”。这种作法的优点，前面已经提到了，在进行划时间段的快速查询中，比用ID主键列有很大的优势。 但在分页时，由于这个聚集索引列存在着重复记录，所以无法使用max或min来最为分页的参照物，进而无法实现更为高效的排序。而如果将ID主键列作为聚集索引，那么聚集索引除了用以排序之外，没有任何用处，实际上是浪费了聚集索引这个宝贵的资源。 为解决这个矛盾，笔者后来又添加了一个日期列，其默认值为getdate()。用户在写入记录时，这个列自动写入当时的时间，时间精确到毫秒。即使这样，为了避免可能性很小的重合，还要在此列上创建UNIQUE约束。将此日期列作为聚集索引列。 有了这个时间型聚集索引列之后，用户就既可以用这个列查找用户在插入数据时的某个时间段的查询，又可以作为唯一列来实现max或min，成为分页算法的参照物。 经过这样的优化，笔者发现，无论是大数据量的情况下还是小数据量的情况下，分页速度一般都是几十毫秒，甚至0毫秒。而用日期段缩小范围的查询速度比原来也没有任何迟钝。聚集索引是如此的重要和珍贵，所以笔者总结了一下，一定要将聚集索引建立在： 1、您最频繁使用的、用以缩小查询范围的字段上； 2、您最频繁使用的、需要排序的字段上。 结束语 本篇文章汇集了笔者近段在使用数据库方面的心得，是在做“办公自动化”系统时实践经验的积累。希望这篇文章不仅能够给大家的工作带来一定的帮助，也希望能让大家能够体会到分析问题的方法；最重要的是，希望这篇文章能够抛砖引玉，掀起大家的学习和讨论的兴趣，以共同促进，共同为公安科技强警事业和金盾工程做出自己最大的努力。 最后需要说明的是，在试验中，我发现用户在进行大数据量查询的时候，对数据库速度影响最大的不是内存大小，而是CPU。在我的P4 2.4机器上试验的时候，查看“资源管理器”，CPU经常出现持续到100%的现象，而内存用量却并没有改变或者说没有大的改变。即使在我们的HP ML 350 G3服务器上试验时，CPU峰值也能达到90%，一般持续在70%左右。 本文的试验数据都是来自我们的HP ML 350服务器。服务器配置：双Inter Xeon 超线程 CPU 2.4G，内存1G，操作系统Windows Server 2003 Enterprise Edition，数据库SQL Server 2000 SP3
SQL Server 索引结构及其使用（三）[转]
实现小数据量和海量数据的通用分页显示存储过程 建立一个 Web 应用，分页浏览功能必不可少。这个问题是数据库处理中十分常见的问题。经典的数据分页方法是:ADO 纪录集分页法，也就是利用ADO自带的分页功能（利用游标）来实现分页。但这种分页方法仅适用于较小数据量的情形，因为游标本身有缺点：游标是存放在内存中，很费内存。游标一建立，就将相关的记录锁住，直到取消游标。游标提供了对特定集合中逐行扫描的手段，一般使用游标来逐行遍历数据，根据取出数据条件的不同进行不同的操作。而对于多表和大表中定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等待甚至死机。 更重要的是，对于非常大的数据模型而言，分页检索时，如果按照传统的每次都加载整个数据源的方法是非常浪费资源的。现在流行的分页方法一般是检索页面大小的块区的数据，而非检索所有的数据，然后单步执行当前行。 最早较好地实现这种根据页面大小和页码来提取数据的方法大概就是“俄罗斯存储过程”。这个存储过程用了游标，由于游标的局限性，所以这个方法并没有得到大家的普遍认可。 后来，网上有人改造了此存储过程，下面的存储过程就是结合我们的办公自动化实例写的分页存储过程： CREATE procedure pagination1 (@pagesize int, –页面大小，如每页存储20条记录 @pageindex int –当前页码 ) as set nocount on begin declare @indextable table(id int identity(1,1),nid int) –定义表变量 declare @PageLowerBound int –定义此页的底码 declare @PageUpperBound int –定义此页的顶码 set @PageLowerBound=(@pageindex-1)*@pagesize …
SQL Server 索引结构及其使用（二）[转]
改善SQL语句 很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如： select * from table1 where name=”zhangsan” and tID > 10000 和执行: select * from table1 where tID > 10000 and name=”zhangsan” 一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name=”zhangsan”的，而后再根据限制条件条件tID>10000来提出查询结果。 事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。 虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。 在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。 SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下： 列名 操作符 <常数 或 变量> 或 <常数 或 变量> …
SQL Server 索引结构及其使用（一）[转]
一、深入浅出理解索引结构 实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别： 其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。 二、何时使用聚集索引或非聚集索引 下面的表总结了何时使用聚集索引或非聚集索引（很重要）： 动作描述 使用聚集索引 使用非聚集索引 列经常被分组排序 应 应 返回某范围内的数据 应 不应 一个或极少不同值 不应 不应 小数目的不同值 应 不应 大数目的不同值 不应 应 频繁更新的列 不应 应 外键列 应 应 主键列 应 应 频繁修改索引列 不应 应 …
解决Windows7无法睡眠(待机)的问题
以前按一下Windows7系统Fn+F4（睡眠快捷键）或点击开始中的睡眠，无线网、硬盘等灯随之就灭了，唤醒必须要再次按下电源按钮。现在win7按了Fn+F4之后，睡眠变的只是黑屏，音量键亮起红灯（音频被禁用），无线网、硬盘灯都还亮着，动动鼠标、键盘就唤醒了。 网上搜了一大堆，基本都在说电源选项的设置问题，但我已按照网友说的，CMD中powercfg -a显示正常，将网络适配器的电源选项“允许此设备唤醒计算机”取消，关闭了混合睡眠，以及Internet Explorer的JavaScript计时器频率设为最大电源节省量（由于SP1导致的），均不奏效。还是动下鼠标windows7睡眠就被唤醒了。 再详细看过文章《详解VISTA/Windows 7 的睡眠和休眠的区别》之后发现最后一段“关于VISTA/WIN7的离开模式(AwayMode)”的一段话，关于里面提到的“离开模式”的状态跟我笔记本表现的状态一致，看来导致我笔记本在交流电模式下无法休眠的罪魁祸首就是这个！具体解决方法是： 1、进入注册表：开始－运行－regedit 2、找到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power 3、在右侧新建一个”DWORD 32位”值, 命名为”AwayModeEnabled”, 并赋值为0（开启为1）
jQuery树形插件：JsTree的简单用法之一－Checkbox 扩展（1）
本代码基于jQuery 1.5.2，jsTree_pre1.0 之前接触了有关jsTree的一些东西，但是后来丢给同事去弄相关的模块，后来他辞职了。今天接手看了下代码，感觉很乱，而且存在一些BUG。借此机会来个修正。 该插件很强大，但是网上比较系统的帮助并不多，争取写成一个系列。 首先基于Checkbox的扩展第一篇：获得Checkbox的选择值。 HTML <div id=”orgTree” class=”treeContainer”> </div> <br /> <div align=”center”> <input type=”button” id=”btnSub” value=” 获取选择值 ” /> </div> 这个是用来承载jsTree的div容器。以及触发事件的按钮。 JS <script type=”text/javascript”> $(function() { /*这就不多说了，注册按钮事件*/ $(“#btnSub”).click(function() { /*通过被选中的样式来获取所有被选中的值*/ $(“#orgTree .jstree-checked”).each(function(){ var node = $(this); alert(node.attr(“id”)); }); …