还有，俺找到这样一个能专门讨论VFP的版块好开心啊！
网上问人家都说VFP太老了你还在用啊……囧
网上问人家都说VFP太老了你还在用啊……囧
所谓的32位、64位，是指程序中的指针尺寸。32位指针是4字节的长度，4字节整数的极限就是4G（机2的32次方），这是这种尺寸的指针所能够到达的最远的地方，亦即内存的最远距离。64位指针，就是2的64次方。操作系统如果是64位的，那么它是能管理的内存很大，但问题是在这个操作系统上运行的程序本身设计的指针是不是也是64位的，如果不是，比如它是32位的，尽管宇宙真的很大（操作系统管理下的内存），但它自己的眼光看不到那么远，就只能仍然到4G处为止。所以，你平时看资料，都应该看过，在64位系统上最好运行64位的应用程序，否则64位系统被当32位用，当初64位系统刚推出，舆论说难以推广，也是指当时64位的应用程序很少。VFP就是32位应用程序，它的能力就只能寻址到4G内存极限。
现在返回说Windows。Windows的管理体系是有特点的，它是面向对象的管理模式，对任何应用程序，它把内存划分为两部分，各占一半，一半是它自己管理的，负责程序使用的系统内核（典型如窗体和各种控件，都是使用Windows自带的东西，你留意一下同一个VFP程序在XP下面跑和在Win7下面跑的窗体是不一样的就知道了，那正是用的Windows窗口，VFP自己没有），另一半才是程序自己的东西，包括指令代码和数据，加起来总共是2G。因此，VFP所能处理的DBF文件，能够调入到内存中进行处理的极限也就是2G，不管你的数据库有多少条记录，只要一个文件加起来的尺寸达到2G，就报警了——所以尽量不要把图片之类的数据放到数据表中的字段中，尽量按第三规范设计数据库，把数据按类别归类到不同的DBF文件，不要把所有数据集中在一起，重点是管理，一个表的字段再多或事实上无法分割，数据量也非常大，那么可以设计把表分开到几个DBF文件中，在程序逻辑上把几个表看成一个表，处理起来仍然是一个表，但单个文件的尺寸却不会超过2G。这种限制其实很容易处理（较难处理的是VFP不能超过10亿条记录）。
留意我上面说的，就知道关键是分割处理数据。你说的那台机，运行很快，仍然是内存的问题，内存够，就快，XP自身占用的内存少，3G内存留下的空闲内存多，就有足够的内存供SQL把数据全部放到内存中处理，当然快，而Win7自身占用的内存比XP多，你2G内存留下的空闲内存更少，就不够了。这里够不够，看两个方面，一是（空闲）内存实际上有多少，二是需要处理的数据实际上需要多少内存。
SQL查询操作所需要的内存很可观，一个表是100M，执行查询需要500M也不稀奇，看操作的复杂度了。像两个表连接之类，SQL在内存中要把两张表按对应的记录排列组合展开成一张巨大的临时表再做筛选的，然后把筛选出来的记录集中放在内存的一个临时表中给你使用，即除了原先的数据，内存中还有一份复制出来的数据表，自己可以想像一下那是怎样的资源消耗。1G的数据表，翻倍到2G以上，有什么奇怪的，正常得很，内存不够，它就写磁盘咯，反复刷写咯，磁盘的速度比内存慢千百倍，改用固态硬盘就快了。
遇到这种边界情形，是需要想办法的，不能靠指令和硬件投资来解决，又不是除了SQL指令之外别无他法。
[ 本帖最后由 TonyDeng 于 2013-3-6 01:34 编辑 ]
没别的 就是内存不足而已 我跑个100多M的3G内存都显得不太给力~
