说，N年前的程序有bug，然而，编译出EXE运行速度没啥问题。
就这么无惊无险平平静静用了好多年，用户也没任何一个投诉，也就没留意。
上个月无意中打开其中几个表，我的天，大的有1千万行记录，小的也有几百万行！

于是我写一段代码，通宵不停地运行了十多天时间，才排查出全部冗余记录。
再写一段代码，删除、替换这一大堆记录，又运行了一个多小时。
删除完，一句close all，又用了将近五分钟，漏斗转不停，我连键盘都不敢按，生怕一动VFP就停止反应，接着强行退出了!
好在有惊无险。

现在问题来啦：

VFP竟然强悍到如此地步，能够随便随便处理上千万行记录，气都不带喘一下，而且还能够让用户和程序员都感觉不到任何反应迟钝？！

连续运行十多天不会挂
什么业务数据只能用一个表文件来处理。
VFP的表宜多不宜大，一千万条记录分成100表来处理可能也是用几多分钟来说。

吹版批评得极是！
都是只读表，针对Rushmore优化创建索引后，SQL查询飞快，也就没留意到表自身存在巨大冗余。
也有可能，当初老眼昏花，将记录数1000万，数漏了一个0，错看成100万了。
VFP处理百万级的表格，湿湿碎啦，这个以前有不少经验。
于是，就这么野蛮地硬生生将这个巨大的错误给生吞了，忽略了。

什么蜗牛代码需要运行10多天, 10多天也能等, 还没感觉到迟钝

普通查询是毫秒级的反应速度。然而编辑、修改一个千万级的表，就太困难啦，运行10多天指的是尝试修改它。

VFP确实很强大，停止更新实属可惜了

RushMore技术失传了

RushMore技术失传了被net升华了(LINQ了解一下，强的一逼)，你不知道而以！不过二维结构打造出vfp这个架框真的很能打在数据表处理目前来说还是王者。PB比它强了那么一丢丢。

[此贴子已经被作者于2025-8-9 11:20编辑过]