如果我们在标识列中插入值，例如： 、

insert member(id,username) values(10,'admin')

则在查询分析器里面会返回错误信息：

引用内容   
服务器: 消息 544，级别 16，状态 1，行 1   
当 IDENTITY_Insert 设置为 OFF 时，不能向表 'member' 中的标识列插入显式值。

有的情况我们需要手动插入标识列的值，例如删除了一些记录后，标识列并不连续，而我们又想把它补齐。我们利用一个开关可以让愿望变成现实：

SET IDENTITY_Insert [TableName] ON

在查询分析器里面这样写：

SET IDENTITY_Insert member ON   
insert member(id,username) values(1,'admin')   
SET IDENTITY_Insert member OFF

<!--[if !IE]><!--> 除IE外都可识别 <!--<![endif]-->
<!--[if IE]> 所有的IE可识别 <![endif]-->
<!--[if IE 6]> 仅IE6可识别 <![endif]-->
<!--[if lt IE 6]> IE6以及IE6以下版本可识别 <![endif]-->
<!--[if gte IE 6]> IE6以及IE6以上版本可识别 <![endif]-->
<!--[if IE 7]> 仅IE7可识别 <![endif]-->
<!--[if lt IE 7]> IE7以及IE7以下版本可识别 <![endif]-->
<!--[if gte IE 7]> IE7以及IE7以上版本可识别 <![endif]-->
<!--[if IE 8]> 仅IE8可识别 <![endif]-->
<!--[if IE 9]> 仅IE9可识别 <![endif]-->

<!–[if lt IE 9]>
加载CSS1
<!–[else]>
加载CSS2
<![endif]–>

对一个服务器程序想统计每秒可以处理多少数据包，要如何做？答案是用处理数据包的总数，除以累记处理数据包用的时间。这里要指出的是， 运行一段程序，使用的cpu时间，跟实际运行的时间是不一样的。附例如下：

    private void ShowRunTime()
    {
                 TimeSpan ts1 = Process.GetCurrentProcess().TotalProcessorTime;
                 Stopwatch stw = new Stopwatch();
                 stw.Start();
                 int Circles = 1000;
                 for (int i = 0; i < Circles; ++i)
                 {
                     Console.WriteLine(i.ToString());
                 }
                 double Msecs = Process.GetCurrentProcess().TotalProcessorTime.Subtract(ts1).TotalMilliseconds;
                 stw.Stop();
                 Console.WriteLine(string.Format("循环次数:{0} CPU时间(毫秒)={1} 实际时间(毫秒)={2}", Circles, Msecs, stw.Elapsed.TotalMilliseconds, stw.ElapsedTicks));
                 Console.WriteLine(string.Format("1 tick = {0}毫秒", stw.Elapsed.TotalMilliseconds / stw.Elapsed.Ticks));
    } 

程序输出如下：

循环次数:1000 CPU时间(毫秒)=50.072 实际时间(毫秒)=666.9071
1 tick = 0.0001毫秒

可以看出在这个例子中，两者差距比较大，其原因如下：

1）Windows是多任务操作系统，按照线程为单位对cpu时间轮询分配。即一个程序运行的中途，可能被剥夺cpu资源，供其他程序运行。

2）程序本身会有不占用cpu时间的等待过程。这个等待可能是我们程序主动的，比如启动一个进程，然后等待进程的结束；也可能是我们没有意识到的，如例子 的Console.WriteLine方法，猜想其内部进行了一系列的异步I/O操作然后等待操作的完成，这其间并没有占用调用进程的cpu时间，但耗费 了很多等待时间。

总结：

1）性能的测量，应该用程序运行时间来测量，当然也需要使用cpu时间作为参考，如果两者差距很大，需要考虑为何出现这种情况。

2）.Net的Stopwatch类可以精确到1/10000毫秒，基本可以满足测量精度。

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.IO;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

public partial class _Default : System.Web.UI.Page
{
private static readonly object SyncRoot = new object();
private DataTable SummaryTable;
protected void Page_Load(object sender, EventArgs e)
{
}

From Orchard Codeplex

我注意到，当我使用如下代码删除的内容项目，它不会删除连接到该内容项的任何部分的现有数据库记录。 例如，AutoroutePartRecord和TitlePartRecord。

_contentManager.Remove(contentItem)

这可能是是移除和彻底删除的想法差异，当您通过ContentManager删除的内容项目时 ，它只是清除在所有版本的发布时间和最新的标志，但留下完整的记录，只是对任何查询透明。 它不是一个记录删除而像一个回收站，数据仍然存在的情况下删除内容是不是你的工作流程的结束。 这是和版本记录您发布版本时总体思路相同，旧版本记录既不是最新的，也不发布时间，但他们像维基，历史悠久的审计，恢复到过去，等场景实际存在。好像这个叫什么软删除。

这在大多数情况下是一个良好的方案，但应该有一个可能，需要永久地删除的内容记录，只是你不一定需要它。

所以，我们得到一个处理办法。ContentHandler中添加OnRemove事件，彻底的消灭它。

public class SchoolHandler : ContentHandler
    {
        public SchoolHandler (IRepository schoolPartRepository)
        {
            Filters.Add(StorageFilter.For(schoolPartRepository));
            OnRemoved((context, part) =>
            {
                schoolPartRepository.Delete(part.Record);
            });
        }
    }

最后引用一个帖子的内容，来说明一般情况下没有必要非得删除它。

磁盘空间时下真的很便宜，甚至在托管计划您的网站可能会工作了很长很长的时间，都难以达到你的主机的空间限制。而且那些数据一般而言，对性能的影响也微乎其微，而且也可做其他优化用空间来换取时间（性能）。如果这真成为一个问题，做清理模块可能将不得不直接在NHibernate做一些结构混乱的东西，但它应该是相当简单的。 但在一般情况下，软删除是越来越普遍，因为他们提供了许多优点。

 

localization files are missing the format used to display published date.

default Parts.Common.Metadata.cshtml declares this :

<div class=”published”>@Display.PublishedState(createdDateTimeUtc: Model.ContentPart.CreatedUtc, publisheddateTimeUtc: Model.ContentPart.PublishedUtc)</div>

And PublishedState shape is declared as follows (in CoreCommonShape.cs) :

return Display.DateTime(DateTimeUtc: createdDateTimeUtc);

And, finally, DateTimeShape.DateTime is :

大家都用过企业管理器中的–“收缩数据库”，里面的功能的确可以收缩数据库的日志文件(.ldf)和数据文件(.mdf)，但都会发现同样的问题，在收缩“数据文件”(.mdf)时根本收缩不了多少。最多截段自动增长部份的，没有根本释放在日常操作中删除数据库的沉冗空间。

上述应该是很多人遇到过的，笔者也千试万试试出来的方法，为了确定您的数据库安全，在执行下例的操作前，请先备份你的数据库。

1.首先你要找到你的数据库最大的表，一般是数目最大的表，如果不清楚，请在查询分析器查询：

DBCC SHOWCONTIG

接着用 sp_spaceused 表 来查询reserved 的值和 data 的值 的差异可看来此表比较沉冗。

2.复制你的转移旧表的数据到新表;

SELECT * INTO 新表 FROM 旧表

(如果你数据比较多，可能你会看到待压缩的数据库对应的mdf和ldf文件大小在猛增，没事在复制表)

注:此命令不能把数据库结结构完全复制，需要您重新把旧表与新表对应的主键，自动增长值，索引，默认值等修改。

3.更新一下;

DBCC UPDATEUSAGE (0)

4.把旧表删除，然后把新表的名字改成旧表的名字，这些可以到企业管理器里操作(注意重命名名时的提示);

5.收缩mdf文件，也是最想要实现的一步;

DBCC SHRINKDATABASE(‘库名’)

DBCC shrinkfile(2,0)

DBCC UPDATEUSAGE (0)

/*

2 -> 要收缩的文件的fileid，对应sysfiles中的fileid。

0 -> 收缩到初始大小

*/

(注:红字是收缩你的数据库mdf文件,时间可能有点长;蓝字是收缩ldf文件;紫字是更新一下，非重要)

完工，这时候你应该可以看到数据库的mdf文件大小变化差异，不说几十M，笔者的数据库就从6G收缩到1G左右，再次执行查询一些数据，明显快多了。

在一个办公室中，有一台elastix服务器，它有很多个分机，当同事分机响铃但同事不在旁边时，我们可以用自己的分机通过拨打相关的号码来代接，主要有两种方法：

第一种：直接拨打*8接听正在响铃的分机，这个一般用于只有一个分机在响铃的情况。

第二种：拨打**+正在响铃的分机号，接听指定的响铃的分机，这个可以用于多个分机响铃的情况。

我们首先介绍第一种方法，这时我们只需要保证自己分机的pickupgroup的值跟要代接的分机的callgroup一致就行(在分机设置中)，比如：

分机5001，callgroup为1，而pickupgroup为空。

分机5002，callgroup为2，而pickupgroup为1.

这样的话，5002可以通过按*8来代接所有callgroup值为1的分机。

而5001因为pickupgroup为空，不能通过拨打*8来代接其他任何分机。

这里我们拿5002作为例子来查看下设置，进入到创建好的分机5002的操作界面，找到callgroup和pickupgroup并对他们进行配置，再点击提交就行。

接着是第二种方法，其实我们也不需要设置什么，只要拨打相应的特征码+正在响铃的分机号就可以了。

例如：5001和5002 都在响铃，5003可以拨打**5001来接听5001的呼叫，或是拨打**5002来接听5002的呼叫。

Elastix可以监听分机吗？当然可以。只要按555就好。可是只能随机监听分机。如何做到监听指定的分机呢。那就要自己写1个拨号规则了。写完后记住要Reload Asterisk不然是无法生效的。

[spy]
exten => _556XX.,1,Macro(user-callerid,)
exten => _556XX.,n,Answer
exten => _556XX.,n,Wait(1)
exten => _556XX.,n,ChanSpy(SIP/${EXTEN:3},q)
exten => _556XX.,n,Hangup
exten => _557XX.,1,Macro(user-callerid,)
exten => _557XX.,n,Answer
exten => _557XX.,n,Wait(1)
exten => _557XX.,n,ChanSpy(SIP/${EXTEN:3},qw)
exten => _557XX.,n,Hangup
include => from-internal

什么意思呢。556是监听，但是监听的人，只能听，没有权限说。比如说801打802通话中。803拨556801，就可以监听他们说话。但是803说什么他们两个都听不见。

但是如果803拨557801是可以听见801和802谈话的同时，803如果说话了，801和802也可以听见，就好像是个3方通话一样。细心的童靴对比后发现，其实区别就是1个q和w.呵呵就是这个控制的了。

include => from-internal 这个是包括elastix的拨号规则的权限，如果这个不写，那就这个分机只有监听的权限，而不能拨打外部的号码了。

建好拨号规则后，我们还要把这个拨号spy规则放入到指定的分机803.中

大功告成。有时候ELASTIX抽风，大家会发觉及时写入了spy到extensions_custom.conf.也会好像没有写入。大家可以检查dialplan show spy 在TOOLS>>Asterisk-CLI里面。敲入

dialplan show spy.如果没有任何输出。那就是拨号规则写入extensions_custom.conf失败。多试下，换浏览器，还是什么的。

如果还是不行，大家下个WINSCP。然后打开/etc/asterisk/ 找到extensions_custom.conf然后添加就好了.

另外,建议大家用BLF功能配合使用监听。

因为BLF功能可以知道哪个话机处于通话状态。比如说801在通话中，801对应的BLF按键，红灯就会闪。然后你只要拨打556801，就可以进行监听了。

较早版本的修改

//srcUmbraco.Core.Models.ContentExtensions.cs
// line 425
// 解决发布URL问题
var niceUrl = contentBase.Name.FormatUrl().ToLower();
    niceUrl = string.Format("item-{0}", contentBase.Id).FormatUrl().ToLower();//增加此行

//srcumbraco.cms.businesslogic.datatypeFileHandlerData.cs
// line 50
//解决上传文件命名问题
var name = IOHelper.SafeFileName(postedFileName.Substring(postedFileName.LastIndexOf(IOHelper.DirSepChar) + 1, postedFileName.Length - postedFileName.LastIndexOf(IOHelper.DirSepChar) - 1).ToLower());
    name = String.Concat(Guid.NewGuid(), Path.GetExtension(name));//增加此行

更新到6.1.0以后的修改