路过秋天

昨天突然兴起，准备完善秋色园后台的编辑器关于Chrome、FireFox下的选择内容的HTML兼容处理,JS编辑器获取选择内容的HTML兼容性写法问题描述：
对于如何获取选择的文本（包括Html标签），通常网络上的答案是：var deditor=document.getElementById('iframe名称').contentWindow;
IE：deditor.pos.htmlText，获得html内容。其它浏览器：deditor.window.getSelection().toString(); 仅获取不包括html标签的文本。
问题：假充你给一段选择的文字（包括换行、段落格式化的），加一个背影或边框等操作时，如果html标签都失踪了，仅剩下文字，那就不是您想要的效果了。

夜里三点多，刚完成微博粉丝精灵V3.763的微博升级，上来看看，刚看到一篇文章：【原】关于使用DataReader的一个很奇怪的问题，不应该用DataReader？
于是准备花点时间解答下，顺便为这个月增添一篇文章。。下面请看：

记得好久好久前发布了：刷微博粉丝工具发布及原理解说，好像是去年中秋的时候了，现在微博粉丝精灵都发布到V3.75版本了，同时也相关的微博人气精灵也发布了V1.8版本，对于玩微博的人来说，粉丝是入门必备的过程，不管是个人还是企业，在微博的初始阶段，都会为追求粉丝数的上升而寻找不同的途径去努力。

早在（新浪）微博粉丝精灵的评论平台（现在移到微博人气精灵）里，需要有空间来显示新浪微博的内容，如下图：在图片的右侧，是一个WebBrowser 控件，用来显示新浪微博的内容给用户评论，然则却遇到不少问题。直接显示Html内容，不像直接导航网址容易处理:问题：按微软的控件属性提示，可以用WebBrowser.DocumentText 属性赋值 ，但是这种赋值，只是首次有效，后续切换都没啥作用。为决定这个问题

某天，为了给微博粉丝精灵增加个老板键功能，找一惯的方式，开始从网络下手寻找： 关键字类似”C# 老板键“，一搜，一堆又一堆，然而出来的代码，基本上都是一个样的：正常来说，老板键一般少不了：Alt+Ctrl+Shift+XX这种多组合方式，然而各类代码就是不直接说明，也没个提示，看来是有意隐藏，终于，还是被我发现其中的一些不为人知的隐藏属性：

服务器内存就512M，Access数据库（文章库）600多M，结果竟然就是IO受伤了。早些年写秋色园技术原理解析系列，园里不少看过的帅歌，应该有点印象，从开始到现在，还是铁打的Access数据库。虽然本人目前对Access恨入之骨，皆因囊中羞涩,暂时不得不与之同流合污。几个月来，秋色园一直运行正常，除了远程界面都变的很卡之外，基本上也没发现什么异常。然而这个隐藏多年的内伤，如果不是那一天，客服把我服务器给关机了，估计到现在也没察觉，让IO受伤了好几个月了。

上篇：半解TextBox灵异事件背后神秘的深度灵异事件，一文中，一共提出两个问题：1：TextBox竟然扯上了User-Agent，是什么让它们生生死死的扯在了一起?2：本地的请求头发出时，被拦截修改成以下内容，是神秘黑客？还是UFO？还是台湾间蝶？：Mozilla/4.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.0.11)

就在前几天，当我来到当下所在的网络时，查看微博粉丝精灵后台时，一件很灵异的事情发生了：TextBox变小了,究竟有多小？我给大伙截一下当前网络下博客园后编辑框：天正想打10086问下看看有没有头绪，再次访问服务器，查看，晕了，恢复正常了！！难道是我发布的文章被“神秘黑客”发觉了，于是故意恢复的？

通过AOP策略，将用户博客变成单数据库查询，直接跳过主数据库Access查询，基本灭掉了Access被并发的机率，同时新的策略，将Access数据库的并发写，变更成队列式写，因此不再有并发锁库出现，对于需要综合数据查询的，仍然返回Access数据库查询综合数据，由于整体是插件式操作，如果有一天access升级换成其它数据库，不需要SQLite配合时，只要注释配置文件代码将插件去掉，依旧是正常的运行，如果用户想独立出去弄个域名，直接把sqlite数据库下载回去即可。

IISLogsViewer 简单IIS日志分析工具 是CYQ系列中的一款用于分析IIS日志的简单IIS日志分析工具，使用简单，分析简单，效果不一般。
新发布V2.0 版本功能完善，增加更详细的分析日志，同时支持大IIS日志文件分析（G单位）。

本版本新增加的功能预览
1：优化Access、SQLite数据库链接，以{0}代表根目录
2：MAction增加指定列的查询功能：SetSelectColumns
3：增加AppDebug类，可以全局输出执行过的SQL语句。
4：增加FastToT的Emit类，提升大数据量时从MDataTable转List<T>的性能
5：关闭默认mssql/oracle的事务开启

好处：事务有需要就打开，默认不打开。

如需要兼容V4.5及以前版本的事务，可使用配置项兼容：<add key="TransationDefaultOpen" value="true"> </add>
......

总结：个人觉得解决完上面的问题之后，基本简单的文本数据库也成型了，当然你也可以往上继续追求。不过文本数据库，折腾的太复杂也没必要，毕竟文本数据库，还是以简单为主。如果NoSql会流行，何不让文本数据库也在.net界也出出风头，成长成.Net界的一朵奇葩！

秋色园 QBlog 对于频繁产生更新操作的访问计数器（用户表及文章表），进行了另一种优化方案处理，使得原来并发进行的操作，变成了定时的单个队列式顺序更新操作，有效的解决了计数器引发的并发的问题。虽然减压方案频繁出招，可是依旧没能阻挡住access黄金4K的绝杀。在压力之下，梦幻潜能再次被激发。于是，新的绝招再次出世：一个失传已久的招数：文本数据库。

之前本有意要发布V5版本的，经过深入考虑和网友交流之后，发现：过快的版本发布，不一定是件好事，因为更多的使用者，更倾向于一个稳定的版本！
同时过快的版本发布，容易让外者对 CYQ.Data 数据框架的稳定性产生一种疑惑性的定向思维！其实 CYQ.Data 从V1.N到V3.N时代，基本是属于一个功能性扩张时期，有很多简化操作和新支持功能的新新元素不断的被加入！接着 CYQ.Data 从3.N版本开始，主核心功能，即数据库操作这块，已经趋于稳定，同时开始经历秋色园和网友项目的洗礼，同时也涉足围绕发展Xml/Html操作。然后 CYQ.Data 到4.N版本时期，主核心功能数据库操作和外围Xml/Html操作，都也趋于稳定，同时性能有了更优的提升。

在上篇：浅说--未将对象引用设置到对象的实例(System.NullReferenceException) 中，介绍了一个比较经典的异常。
文中并浅出一些个人观点，又潜伏一些观点。本节将从上篇的文章中，引申潜伏在上文的另一个主题：异常霸气外露！找死！

System.NullReferenceException：未将对象引用设置到对象的实例，这是一个新鸟，中鸟，老鸟都避不开的错误。这是为何呢？中鸟何以追求性能？老鸟何以不太关注性能，而求稳定？本视频将为你解答，敬请收看：

最近都在写 秋色园技术原理解析 文章，今天就写一篇散文，简述一下服务器内存太小引发的命案。以前写文都排版，这篇就当散文了...写完就这样了，当然加黑加红还是给加了。首先，我先上2张秋色园服务器当前进程及内存的图片：看完这两张图片，啥感觉？内存穷紧张！！！！穷紧张不打紧，打紧的是比紧张还紧张的情况发生了，什么情况？出事故了，应用程序池要产生回收动作了！！！！

上节 秋色园QBlog技术原理解析：性能优化篇：access的并发极限及分库分散并发方案(十六) 中，

介绍了 Access的并发上限，及从某种程度上 秋色园QBlog 针对并发上限进行了多个数据的划分，从而最大并发上限从64提升到64*N（个数据库），虽然总和的最大并发值是上升了，但是单个库的最大值并没有变化，或者说单个表的最大并发值没有发生变化，上限仍是64。

于是，对于频繁产生更新操作的访问计数器（用户表及文章表），是该进入优化的方案了。

本节将介绍秋色园 QBlog 的Super分库方案，以及何以如此Super分库的原因。Access并发极限的分析在写此文前，我做了一个小小的代码测试，通过这个小测试，终于解惑了我对access究竟支持的是怎样的并发和黄金4K的.ldb文件的概念。如果这是access单个数据库极限并发的答案，总结就是：access最大支持同时打开64个链接，每个链接产生64个字节，看到黄金4K的.ldb文件，说明极限到了。而且，这是一个数据库的极限，因此，你想获得更大的并发数，不是分表，而是分库。以上是对一个数据库的最大极限测试，那会不会对数据库的单个表存在着最大极限并发？

上节回顾：上节 秋色园QBlog技术原理解析：性能优化篇：缓存总有失效时，构造持续的缓存方案(十四) 中，
介绍了 秋色园QBlog 在性能优化方面，为了避开缓存失效的空白期，特意使用静态化方式做为临时缓冲策略方案。
本节内容：本节将介绍秋色园 QBlog 从另一个角度上的网站优化方式：数据库分表分库基础优化。