比方说：
update 地址汇总表 SET 已处理 = .t. , 联系地址 = strtran(联系地址, trim(地址更新表.旧串), trim(地址更新表.新串)) from 地址更新表 WHERE 联系地址 like "%"+trim(地址更新表.旧串)+"%" .and. ! 已处理
大意是，地址定期更新时，凡带有“向阳西路”的，统一更换为“爱麦斯西路”，“明水区”的，统一更换为“高新区”。“地址更新表.dbf”中保存对应表：

旧串, 新串
"向阳西路", "爱麦斯西路"
"明水区", "高新区"
...

where条件若为like、like()或者atcc()，当数据表较大，达到10W+甚至更多记录时，运行起来会狠慢。
索引“联系地址”、“旧串”等字段，好像并不管用。

replace也根本无任何速度优势啊，一样一样的：

select B
use 地址汇总表
select A
use 地址更新表
scan
    * select A
    lcOldStr = trim(A.旧串)
    lcNewStr = trim(A.新串)
    select B
    replace 已处理 with .t. , 联系地址 with strtran(联系地址, lcOldStr, lcNewStr) for atcc(lcOldStr, 联系地址)>0 .and. ! 已处理
endscan

这一点确实我没想到，很具性价比的顺序调整建议！非常感谢！



join这个关键词，振聋发聩，我得好好思考一下！非常感谢！

第一版实在太慢，确实“旧串”不唯一；不过后来无意中我也发觉到了，第二版重新做了一个unique旧串表，然而速度并未有实质性提升。
仍是巨慢。哪怕换一台最新i7电脑32G内存，也没多少改善，得到的印象，近乎是当年586/2G的速度。

若不想费时费力去构造SQL语句，那么转用VFP的“土话”——用Replace替代——有时候确实是非常高效，非常优异的，速度快出不仅仅是一个量级，而是“指数级”！

吹版在搞事情！
无辜躺枪，传说中的16楼，表示严重关切，严重不满！
没错儿，我老人家平时没别的嗜好，就喜欢吹吹水、抬抬杠。
然而也挑对手的。
不是一切场合皆有兴致参与掰扯的。
你们PK你们的，我老人家搬张板凳来，只负责吃瓜，不负责动口。
——我又不是君子。

讲真，因最初是从DBASE III起步，小时候熟悉的完全是xBase“土话”那一套，SQL的语法，若不是恰好读到章立民《应用实务篇》，还真不太了解。
后来当然知晓了SQL的强大。
心服口服。
只不过，在做单机版的软件时，选择用Replace还是Update，那几乎纯是个人喜好，好像看不出太大差别。
SQL语句写得不好时，可能还真的远不如索引+“土话”高效！
只因SQL需要很细致分析、优化，而“土话”几乎不用过脑，顺序写下来，程序就能飞速运转起来，并得出了所需结果。
当然，这么说，绝无企图挑战SQL高手的意思——只因VFP的土炮实在太过强悍，导致有时似乎无必要发射导弹去打蚊子。
我说，是吧？