由于“栏目结构管理”部分需求的更改，今天不得不把以前的代码再翻出来更改。改代码总是Bug越改越多，新的功能是实现了，但是不稳定，总在某些情况下总是不行。
经过一个小时的反复实验，发现问题出在Dataet上。晕了，又是它……
还是老办法，单步执行，虽然这个方法很好用，基本bug都可以被找出来，可全神贯注的盯着显示器可不像盯着美女那么爽，那些蚂蚁啃出来的代码毕竟不那么具有吸引力-,-
果然跑了三遍都没看出什么，只是证明了三次错误会在这种情况下发生。唉～看来今天不是debug的日子，于是趴在桌上睡着了 ZZzzzz…..
一觉醒来发现已经是吃饭时间，“不行啊，不能什么事情都没做就去吃饭，怎么对得起白花花的米饭？”我终于良心发现，重新打开Visual Studio，一定要把bug搞定。
睡了一觉果然效率高，一遍跑下来就发现了问题。
一张只有一行的表:tTable.Rows.Count == 1
我删了一行:tTable.Rows[0].Delete();
行数显示仍然是1：tTable.Rows.Count == 1
莫非DataRow类有Bug？人总是这样，出了问题总是先找别人的错误。不懂怎么回事，我竟然想到了Bill Gates，在对他的崇敬与厌恶的感情上又多了一份愤恨！bug总是没完没了…
说归说，骂归骂，该做的事情总是得做，debug总是得继续。
跑了几遍下来，同样的结果，但是我却束手无策。想了一下，如果是DataRow.Delete()函数出问题的话，我是不是应该看一下这个函数到底做了什么？于是我展开DataRow的所有属性，单步执行看经过Delete函数时哪些属性被改变了。
果然不出我所料，很多属性都被改变了，比如DataRow.ItemArray被清空了，也就是这行的数据已经不存在，但为什么它不删除行呢？到这里我突然想到，DataSet是支持回滚操作的，难道是为了实现这个才这么做的吗？
再往下看，有个属性一下子吸引了我，RowState == Deleted。我一下子变得很兴奋，把程序再跑一遍，仔细观察了RowState的变化，发现调用DataRow.Delete()以后RowState从UnChanged变成了Deleted。
真是黄天不负有心人，又搞定了一个隐蔽的bug。现在我可以用tTable.Rows[0].RowState来判断而不用tTable.Rows.Count了。
看来还是基础不扎实，快餐吃出来的.NET果然不灵的，很多底层的东西不了解，得弄本书好好看看。
Debug就和恋爱中的矛盾一样，往往谁都没有错，错在相互不了解。