对于这种情况, 建议您直接在VS.NET中加载微软官方发布的.NET Framework Library的Symbol文件来进行调试. 目前System.Data命名空间下的.NET Framework的源代码是开放的,并且可以通过VS.NET在线阅读来调试. 您可以通过阅读DataTable部分的源代码来查明是否是.NET Framework本身的问题.
我觉得造成这种现象的原因是这个 DataTable 在它生命周期中没有被很好的释放和重新填充，只需要增强数据的逻辑处理，在适当的时候对 DataTable 清空数据，就可以解决。
比如在每次 select 返回数据到 DataTable 之前都把这个 DataTable 先设为 null 再用新数据重新赋值，应该就不存在这样的问题了。
可以通过在线的 MSDN 获得帮助：http://msdn2.microsoft.com/zh-cn/library/
DataTable 只是将表格化数据表示为内存中的一个包含行、列和约束的表格，如果说它本身的设计有问题，那么现在 .NET Framework 版本号已经 3.5 了，我相信不会不修正吧，所以我们在这里的讨论先排除这个原因。
因为最初运行一段时间没有问题而之后出错，可以由此判断，在运行过程中对数据的增删操作存在误差，应该结合系统环境综合评定到底是哪里的错误。
DataTable.Select 方法请参考文档。
不知道你使用什么方法来“删除”DataTable中的数据的，某些删除方法只是将DataTable的某行的状态置为Deleted，而DataTable中实际上继续保持对这个“被删除”的行的引用，某些删除方法则是物理的将某行从DataTable的Rows集合中移除。
另外你用Select的那个参数版本的重载？因为上面删除方式的不同，加上你用Select方法的重载版本的不同，你有可能会Select出来那些被标记为Deleted的但又继续被DataTable引用的行，从而导致DataTable的Rows.Count = 0而Select返回1700行。
我MSDN上找过了,最近是有DATATABLE的HOTFIX,解决的也是SELECT返回异常的问题,但具体内容与我遇到的有点差异.由于这个程序通常在这个DATATABLE对象被使用几天之后才出现问题,而且并不抛出错误.因此很难定位.如果有dotnetframe的PDB,在出现问题时应该不难定位的.
我使用的是DataRowCollection Remove (DataRow row),MSDN说"调用 Remove 等同于先调用 Delete 再调用 AcceptChanges。", 而Select 使用的是DataTable.Select (String) ,如果System.data中本身没问题没理由出现这种情况的.
今天才发现关于 DataTable 的 FIX 还真不少。
判断一下
超过一定时间 生成一个新的datatable，把数据复制过去
使用这个新的datatable
