清凉水都

1.对于引用的处理
FORALL在使用集合的时候无法用引用的方式调用数据，例如:

Forall i in tab.First .. tab.Last
   delete  Table where col = tab（i）.col

这样是无法编译通过的，所以不要指望用Selete * Bulk Collecte into row_tab到一个记录集合，在通过FORALL的方式来快速处理表格数据了，要做的话只能用标准SQL语句解决了，或者一列一列的改（注：多集合的情况下，FORALL会默认按FOR……LOOP的方式处理数据，就谈不上优化了）。

2.关于异常处理的一些例外和机制猜想
虽然Forall可以通过调用Save Exceptions和块的Exception来跳过错误继续执行后面DML，但是当因为调用的集合缺失数据而发生错误的时候并不一定会跳过继续进行，下面举个简单的例子：

Declare
TYPE t_tab IS TABLE OF Varchar2(3);

v_tab  t_tab := t_tab('1','2','3','4','5','6');

BEGIN
v_tab.DELETE(1);
v_tab.DELETE(2);
v_tab.DELETE(5);

FORALL i IN v_tab.FIRST .. v_tab.LAST SAVE EXCEPTIONS
UPDATE  TestTable  SET t_value = 'Changed'
WHERE   t_id = v_tab(i);

DBMS_OUTPUT.PUT_LINE('END');

EXCEPTIONS
WHEN others THEN
NULL;
END;

这个结果是不是看起来很奇怪，如果按照无SAVE EXCEPTIONS的情况下去想，那么结果都应该为Unchanged,如果按照有SAVE EXCEPTIONS的一般情况来想则6应当为Changed。

根据FORALL的处理流程和上面的结果，我个人认为FORALL在执行的时候是这样的：

1.生成所有集合记录执行的DML语句
2.将所有语句一起发送给执行器执行
3.执行器逐条执行语句，和For……Loop的方式相似，自动提交和回滚每条记录

因为只提交一次DML所以在集合中有多条集合时，效率会大大优于For……Loop。那么产生上述问题的原因就在第一步生成DML语句的时候了。由于1和2的数据不存在，无法产生DML语句，于是继续检索后面的集合，到3的时候可以正常生成。到5的时候又不能生成了，关键点就在这之后的处理了，引擎并没有尝试去生成后面的语句，而是直接跳出的生成环节，所以6理所当然的没有被更新了，因为根本没有生成对应的语句。

因此对于添加SAVE EXCEPTIONS的FORALL的错误处理，是分为两个部分的：

1.在生成语句阶段，引擎是从生成第一个正常语句开始到再遇到错误截止，换句话说只能跳过头部的连续错误，而中间的错误会影响其后面的操作。
2.在执行阶段，各个语句相对独立，任何错误都不影响其他语句的执行。

最后，建议各位在使用FORALL的时候最好用变长数组（VARRAY）不要用 嵌套表(TABLE),嵌套表是不连续的，而且变长数组（VARRAY）可以避免删除操作，如果实在需要用嵌套表(TABLE)的话，一定要记得检查是否有空数据，然后用TRIM彻底删除后，再用FORALL执行，以避免发生上述问题。

作者：e-bread   

在使用VisualStudio的时候，大家可能对内置的IntelliSense功能赞叹不已。高高兴兴的自己写个类，发现这个所谓的IntelliSense并不买账，怎样才能实现.Net系统库那样的IntelliSense功能呢？其实.Net内置了一个XML文档注释功能，VisualStudio可以根据生成的XML文档注释内容，通过反射机制，从而实现IntelliSense功能。当然如果你对反射足够了解，也可以自己分析生成的XML文档，不过这部分不是我们这次关注的问题。

打开MSDN，搜索XML文档注释，你会发现.Net提供了大量的文档注释标记，实际上多数标签对于VisualStudio的IntelliSense来说是没有用的，能用上的也就那么几个，其余的是做其它用处的，例如类型检测等，由于是初步，也就不多说了。啰嗦了半天，下面进入正题，能被IntelliSense识别的标签是：<summary>,<param>,<exception>，换句话说只有这三个标签的内容会显示在快捷信息中。下面我们看一个例子。

       /// <summary>
      /// 这是摘要信息
      /// </summary>
      /// <param name="i">参数1信息</param>
      /// <param name="fl">参数2信息</param>
      /// <exception cref="System.Exception">异常信息，在Cref中制定错误类型</exception>【！注意这里是一行，由于页面宽度换行了。】
       public string SampleMethod(int i, bool fl)
       {   return " " ;}

细心的人应当发现了，这里注释行前用了三个"/"而不是常用的两个"/"，这是XML文档注释的特征，说明这些注释是要编译的，否则不编译。当然类似块注释，XML注释也可以用"/**  */"进行块注释。不过和一般的块注释不同，XML 的注释块中间的每行前都要加一个"*"，看起来是这个样子：

    /**
     * <summary>摘要信息</summary>
     */

个人感觉还不如单行方便，而且VisualStudio在块的情况下的IntelliSense支持不好，不会自动添加结束标签，个人不建议使用这种注释方式。

由于是XML文档注释，因此除了前面的“///”外，格式是符合XML规范的，<summary>标签显示对应的摘要信息，<exception>则根据"cref"引用的类型显示异常信息，这两个标签会在IntelliSense成员列表的快速信息中显示，以上面的例子显示如下：

string SampleMethod(int i, bool fl)
       这是摘要信息
Exceptions:
      System.Exception

对于<param>标签，则根据"cref"引用的参数名，根据你在键入的对应函数显示对应的提示信息，例如你在上例中输入参数fl,则快捷信息显示为：

string SampleMethod(int i, bool fl)
 fl：参数2注释

我们可以发现异常信息并没有显示出来，并不是VisualStudio没有识别，只不过没有放在快捷信息中，打开对象浏览器（object  browser）这些信息就出来了，其实想<remark>,<returns>也会显示在对象浏览器中，不会显示在快捷信息中。因此我们可以将备注信息和返回值的详细信息写在这两个标签中，当需要查看是可以到对象浏览器中仔细查看。

只要遵守XML注释规范，那么你的代码也可以智能感知，花一点时间写这些注释，会大大提高后面的工作效率，多人合作更是如此，还不赶快去试试！

WPF中的Page调用States类中的Replay方法恢复Page（换句话说原Page的恢复信息保存在State中），
根据这个特点，我们可以继承CustomContentState，将Replay的实现改为调用外部委托实现个性化历史记录,委托的传入参数最好是继承的自定义State本身，例如自定义State名为CustomState，则委托声明为 public delegate void ReplayCustomState(CustomState state),Replay函数里只写ReplayCustomState(this),最后在CustomState构造的时候赋值给ReplayCustomState就可以了。

此外Replay方法中的具体恢复过程是针对具体要恢复的Page页的。
例如Page中有个Label名为lblName。对应数据State中存储的数据为string Name。
Replay(CustomContentState state)中则写 lblName.Text = state.Name;

虽然自定义了State，不过WPF可不认这一套，最后还要我们将自定State手动记录下来，通过NavigationService的AddBackEntry（CustomContentState）来存储State就可以了，在想存储的地方调用这个方法就可以实现自定义历史记录了，如果根据用户的特定操作记录的话，还可以实现历史回顾特性的撤销功能，和PS很像（不过这个实在历史记录按钮里）

由于自定了State，WPF原有的历史功能就不好用了，因为它在历史功能中存储的还是系统默认的State，这可不是我们想要的结果。于是要自己写个历史程序，还好只要Page继承IProvideCustomContentState接口就可以了。

IProvideCustomContentState提供一个抽象函数 public CustomContenState GetContentState()，GetContentState()在Page触发历史变更按钮的时候触发，返回CustomContentState，所以我们可以返回自己的State，从而存储自定义State，实现历史功能。在返回自定义State前要给JournalName赋值，用于标识不同的State。
虽然在反编译时，会看到当JournalName为空时，WPF自动给它赋值了，不过没有这个在实例CustomState是无法编译的，还是老老实实写上。
多说一句，实际中State存储的JournalName是你输入的JournalName+#+容器名，从而区分不同容器相同JournalName的情况（因为容器名肯定不同）。

此外，WPF对历史页面调用GetContentState()存储State进行了位置检测，换句话说，如果你在历史界面继续跳转，那么除了传入的State会变外（看你怎么生成传入的State了），State在历史记录中的位置是不会变的，

举个例子，例如你跳转到第二步的Page，名称为Step2，在历史展开列表中从下向上数在第二位置，对页面数据无改动后继续跳转，GetContentState()触发，将传回的Sate中的JournalName改为Step5，那么历史列表中从下向上数第2项更名为Step5 而不是列表的第5项。当然如果你对页面数据进行了修改，那么这个就是倒数第二个
选项了（第一个为当前页），原先Step2后的历史记录清除了。

总结一下，自定义历史记录的实现过程，首先通过继承抽象类CustomContenState，实现Replay（NavigationService navigationService, NavigationMode mode）方法，再在Page页中利用NavigationService的AddBackEntry（CustomContentState）存储历史信息。最后通过将Page页继承IProvideCustomContentState接口，实现GetContentState()方法，实现历史按钮的功能，至此WPF中Page自定义历史恢复完全实现。

椋鸟：草原灭蝗的“生物武器”[组图]

中国网 china.com.cn　　时间： 2008-07-15　　发表评论>>

7月9日，椋鸟口衔蝗虫在当地牧民为它们搭建的石堆巢上，准备喂食幼椋。新华社记者 沈桥 摄

7月9日，椋鸟在当地牧民为它们搭建的石堆巢上，喂食幼椋蝗虫。新华社记者 沈桥 摄

椋鸟：草原灭蝗的“生物武器”[组图]_中国网

椋鸟：草原灭蝗的“生物武器”[组图]

中国网 china.com.cn　　时间： 2008-07-15　　发表评论>>

成群的椋鸟在新疆巴里坤草原上捕食蝗虫（6月12日摄）。

椋鸟是国家二级保护鸟类，以蝗虫为食，每天捕食蝗虫在120至180只左右，每只椋鸟可保护2亩草场避免蝗虫危害。每年6月初，幼椋陆续破壳之时，椋鸟采食量会大大增加，而此时往往正是蝗虫肆虐之时。 为了给椋鸟提供一个安静舒适的“家”，招引椋鸟防治草原蝗灾，近年来，新疆在天山草原上实施人工筑巢招引椋鸟治蝗工程，据不完全统计，目前，新疆伊犁、阿勒泰、博尔塔拉等地共筑巢招引椋鸟300万只以上，控制蝗虫灾害面积600多万亩。 新华社记者 沈桥 摄

7月9日，椋鸟口衔蝗虫在当地牧民为它们搭建的石堆巢上，准备喂食幼椋。新华社记者 沈桥 摄

椋鸟：草原灭蝗的“生物武器”[组图]_中国网