看清楚，我不仅仅是要求查询，最关键的是要求在很短的时间内（1分钟）增加25000条记录！ 各位可以试一下，建立一个8个字段的表（数据库随便），建立一个循环，不停的增加，看增加25000条记录要多长时间！至于记录多不是主要问题，查询也可以很简单！例如我说的那个飞仔记录表，我要的查询仅仅是： SELECT 姓名,SUM(飞仔工资) FROM 飞仔表 GROUP BY 姓名 WHERE 日期＞XX AND 日期＜XXX 其中飞仔表一个月大约120万条记录，员工数大约1500名，各位可以试一下！如果是年薪要统计，那就算了，从1500万条记录中搜索那么多数据，我感到怀疑！
不好意思，各位都集中到我的问题上来了，谢谢了，不过我相信这肯定也是大伙要解决的问题 我干脆把VFP的源代码写出来，相信如果你做软件两年以上应该能看懂这些代码（过滤掉了出现错误的提示信息），OK！&&SELCUTCODE 是全局变量，记录当前剪裁的裁床编号 SELECT SIZES,CUTRATIO FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTRATION COUNT TO REC &&取出要剪裁的尺码及尺码比例 SELECT SUM(CUTRATIO) FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO ARRAY SUMRATIO &&尺码比例合计 IF SUMRATIO>0 DIMENSION RATIO(SUMRATIO) &&将尺码按顺序及数量转入到一个数组 SELECT CUTRATION GO TOP HEAPQTY=0 FOR SIZESQTY=1 TO REC FOR RATIOQTY=1 TO CUTRATION.CUTRATIO HEAPQTY=HEAPQTY+1 RATIO(HEAPQTY)=CUTRATION.SIZES ENDFOR RATIOQTY=1 SELECT CUTRATION SKIP ENDFOR SELECT TABING COUNT TO REC &&取飞仔的流水号存入变量MAXTABCODE IF REC>0 SELECT MAX(TABCODE) FROM TABING INTO ARRAY MAXTABING MAXTABCODE=MAXTABING RELEASE MAXTABING &&释放SQL语句取出的数据 ELSE MAXTABCODE="0" ENDIF SELECT CUTCODE,ORDERCODE,SHORTNAME,FABRICQTY FROM CUTELEMENT WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTELEMENTN COUNT TO REC &&取出要剪裁的布料数据 IF REC>0 MAXBED=THISFORM.PAGEFRAME1.PAGE1.TEXT4.VALUE &&得到床次数据 FOR SIZESQTY=1 TO SUMRATIO &&将存入数组的尺码资料循环存入飞仔表 SELECT CUTELEMENTN &&取布料数据 GO TOP FOR FABRICQTY=1 TO REC &&将出入SQL结果中的布料数据循环存入飞仔表 MAXTABCODE=CHRTRAN(STR(VAL(MAXTABCODE)+1,8)," ","0") &&下一行是将所有要求的数据转入飞仔表，每次大约2000条记录 INSERT INTO TABING(CUTCODE,TABCODE,ORDERCODE,CUTBED,SIZES,COLORS,QTY) VALUES(CUTELEMENTN.CUTCODE,MAXTABCODE,CUTELEMENTN.ORDERCODE,MAXBED,RATIO(SIZESQTY),CUTELEMENTN.SHORTNAME,CUTELEMENTN.FABRICQTY) SELECT CUTELEMENTN SKIP ENDFOR ENDFOR SELECT TABING TABLEUPDATE(.T.) &&保存结果 ENDIF ELSE ENDIF然后剩下的一样，将这次产生的记录转入一个表打印出来，然后转入员工工资记录表，差不多了，可以列一下代码SUMSERIAL=ORDERING.SERIALNUM &&取出工序数量 SELECT * FROM TABING WHERE CUTCODE=SELCUTCODE INTO CURSOR TABINGN SELECT TABINGN COUNT TO REC GO TOP FOR CUTQTY=1 TO REC FOR SERIAL=1 TO SUMSERIAL SELECT SUMWORK &&下行省略了具体数据，只说明意思 INSERT INTO SUMWORK(...) VALUES(...) ENDFOR SERIAL=1 SELECT TABINGN SKIP ENDFOR就是这样一个例子，如果工序数为12，那么这次就会产生24000条记录，不幸的是昨天有人告诉我他以前在UNIX下用C写的一个制衣软件工序会超过99个，死了！至于DELPHI下的代码，我就不用写了，我试过了VFP、Paradox、SQL-SERVER三种数据库(25000条)，速度都不敢令人恭维！其实就是上面那一点点代码，我想各位再怎么优化也优化不了那里去，这不是由数据库来完成！
多用户中最好使用缓冲更新
应该熟练操纵Sql.当然, 有时为了快速开发, 可以用一些第三方的控件包.
如: DEVEXPRESS系列.2.至于哪种方法使后台出现的错误最少？
不好说.
主要取决于你的代码质量.3.在用缓存更新前,问问自己, 你真的了解了DELPHI的缓存更新机制吗.
缓存更新, 最好是你自己来控制.举一个简单的例子. (对象)列表.
我以前一直用FOX/C写，刚毕业时赶上“九七工程”，用PB！由于讨厌这份工作，所以下决心不搞PB！后来是用VFP或者BCB，但是问题就是出在这儿，DELPHI/BCB速度太慢！
我见过一套“行程控制”（类似于MRPII的数据分析计算）软件（创作于台湾），用DELPHI+SQL-SERVER，要求很高——服务器端要求至强500，256M以上，客户端要求PII350，64M以上，就是这样也很慢！
去年我们几个合作用VFP写过一套制衣厂的管理软件，现在想重新用DELPHI/BCB写，发现太难，下面我具几个例子：
1、每匹布均有记录（编号、颜色、染缸号等），但是很不幸，这家工厂每年的裁布量为1000万匹！
2、算计件工资，产生飞仔，每裁一次大约产生2000条扎号（记录制衣过程的一种编号）记录，然后产生计算工资的飞仔条，如果一件衣服经过12道工序，那就是24000条（记录飞仔凭证），这些都是由系统自动产生，如果用VFP，产生这么多记录大约需要45秒，如果用BCB，5分钟没有完成（C333，128M）！如果一个月下来大约120万条，那算起工资来如何得了！
各位能否告诉我，用DELPHI一下产生25000条记录大约需要多长时间？
另外：用VFP从20万条记录检索出1000条记录只需0.3秒，在DELPHI中死机！各位能否告诉我需要多长时间？
这么庞大的数据量简直头大！原来用手工要8个人（1500员工），用电脑只需一个，看着想吧！ 我见过的制衣管理系统都是用VFP或PB开发，关键是数据速度以及复杂的报表！难道DELPHI没有这么高的数据库访问速度吗？
我現在也正在做類似的系統,因為所有查詢,數据交換都在服務器端完成,所以影響客戶端速度的主要是界面顯示.不太可能速度這樣慢.
各位可以试一下，建立一个8个字段的表（数据库随便），建立一个循环，不停的增加，看增加25000条记录要多长时间！至于记录多不是主要问题，查询也可以很简单！例如我说的那个飞仔记录表，我要的查询仅仅是：
SELECT 姓名,SUM(飞仔工资) FROM 飞仔表 GROUP BY 姓名 WHERE 日期＞XX AND 日期＜XXX
其中飞仔表一个月大约120万条记录，员工数大约1500名，各位可以试一下！如果是年薪要统计，那就算了，从1500万条记录中搜索那么多数据，我感到怀疑！
速度,请参考李维的<Delphi3从入门到精通>,里面有很多地方讲到如何优化数据库访问速度的
问题,我也曾做过一个电信的项目,很简单,把交换机里的数据倒到Sybase里,上千万条记录,包括
计算及合并在内,竟花了六七个小时,后来仔细优化,包括Delphi以及sybase,只花了不到半个小
时.
如果客户端先对各字段值进行复杂处理,这个过程一定是delphi>pb>vfp
存在便是合理,vc代码效率>delphi,如果你的设计不合理vc<<delphi
存在便是合理,vc代码效率>delphi,如果你的设计不合理vc<<delphi这种说法听起来有道理.但:1. 如果一种框架本身就是有限制的, 你还能指望它做什么大东西!
2. 设计的确重要,只可惜真正会大型系统设计的实在太少(一个有100人公司里不会超过5个人).
李维的<Delphi3从入门到精通>
1.李维的书读第一遍\ 佩服
第二遍还是\佩服
照着做\没用.李维的书里你看不到任何一句说DELPHI有什么不好的话.但是李维的身份是什么: INPRISE的台湾代言人.
就象徐新华: INPRIES 的中国大陆代言人.(李维的书(DELPHI方面的)我基本上都有包括台湾版的)据我了解:(我在做项目中接触过的客户)有一些财务软件使用DELPHI 的MIDAS技术做的.
这没什么错因为财务软件往往用户少交易量不大系统相对封闭.用得是地方.国内MIS就不要讲了大部分都是DELPHI.(我也是)不能因为自己用一种东西就说它好的不得了,这不是一个职业程序员的正确态度.
//1. 如果一种框架本身就是有限制的, 你还能指望它做什么大东西!
//2. 设计的确重要,只可惜真正会大型系统设计的实在太少(一个有100人公司里不会超过5个人).
首先每种框架都有限制,人可以绕过一些限制实现功能,如果你觉得delphi太限制你的才华,你可
以用其他语言,没人逼你.如果你没有见过delphi做的大系统,建议多去网上瞧瞧,再发言,拜托!
如果你们搞大型系统却没大型系统设计人员,赶紧散伙吧,我保证你们一定玩完如果从头到尾没有
合理的设计.
//引用:
//不能因为自己用一种东西就说它好的不得了,
//这不是一个职业程序员的正确态度.
首先我没说delphi好的不得了,我确实用delphi,可我也用vc,有的东西实现来用vc确实比delphi方便,可有的方面delphi又比vc方便,他们可以取长补短而已.
开个玩笑:
省省吧你!改什么程序设计语言?你知不知道你不用delphi一点性格都没有了?好好的去做delphi程序设计这个很有前途的职业去吧!
有类似oracle之类的后端阿。
不过我以前测试过linux下sybase，发现它插入数据的效率令人不敢恭维，用来记录
路由器的log信息会迅速被路由器抛离，而且还是校园级的，不是电信级的。
插入速度大约去到100-800条/秒；飞崽条应用要求如果是插入的话，连我这个
测试床都顶不住。但是如果内部产生速度应该足够，但如果这样好像令人费解，
从数据库内部产生的东西，和工厂的流程岂不是脱钩了？不过即使是插入，换上
牛一点的机器跑sybase，速度还是可以满足飞崽条应用的需要的的。关键这些速
度和用delphi还是什么其他的无关。至于用delphi的本地数据库，可能会比较差。另外数据库服务器在同等配置的机器上，速度方面可能会比fox差一些，因为fox不需要
象数据库服务器那样做写回滚段等工作。还有midas我觉得也挺不好用，我们以前用的一个程序，才万把条记录，但是字节数比较多，
结果挺慢的。但那是delphi4.0的了，5.0的好像有新机制了。那位97年就玩MIDAS的兄台不知道现在还有没有玩？现在的MIDAS和97年的MIDAS有了些进步
了嘛。另外诸位兄台的高论看的小弟佩服不已，却也胡涂不已：似乎结论是大型数据库应用应该用
vc+sql服务器来做？不过小弟听说华为就是这么做的。也许真的如此吧。
我干脆把VFP的源代码写出来，相信如果你做软件两年以上应该能看懂这些代码（过滤掉了出现错误的提示信息），OK！&&SELCUTCODE 是全局变量，记录当前剪裁的裁床编号
SELECT SIZES,CUTRATIO FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTRATION
COUNT TO REC &&取出要剪裁的尺码及尺码比例
SELECT SUM(CUTRATIO) FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO ARRAY SUMRATIO &&尺码比例合计
IF SUMRATIO>0
DIMENSION RATIO(SUMRATIO) &&将尺码按顺序及数量转入到一个数组
SELECT CUTRATION
GO TOP
HEAPQTY=0
FOR SIZESQTY=1 TO REC
FOR RATIOQTY=1 TO CUTRATION.CUTRATIO
HEAPQTY=HEAPQTY+1
RATIO(HEAPQTY)=CUTRATION.SIZES
ENDFOR
RATIOQTY=1
SELECT CUTRATION
SKIP
ENDFOR
SELECT TABING
COUNT TO REC &&取飞仔的流水号存入变量MAXTABCODE
IF REC>0
SELECT MAX(TABCODE) FROM TABING INTO ARRAY MAXTABING
MAXTABCODE=MAXTABING
RELEASE MAXTABING &&释放SQL语句取出的数据
ELSE
MAXTABCODE="0"
ENDIF
SELECT CUTCODE,ORDERCODE,SHORTNAME,FABRICQTY FROM CUTELEMENT WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTELEMENTN
COUNT TO REC &&取出要剪裁的布料数据
IF REC>0
MAXBED=THISFORM.PAGEFRAME1.PAGE1.TEXT4.VALUE &&得到床次数据
FOR SIZESQTY=1 TO SUMRATIO &&将存入数组的尺码资料循环存入飞仔表
SELECT CUTELEMENTN &&取布料数据
GO TOP
FOR FABRICQTY=1 TO REC &&将出入SQL结果中的布料数据循环存入飞仔表
MAXTABCODE=CHRTRAN(STR(VAL(MAXTABCODE)+1,8)," ","0")
&&下一行是将所有要求的数据转入飞仔表，每次大约2000条记录
INSERT INTO TABING(CUTCODE,TABCODE,ORDERCODE,CUTBED,SIZES,COLORS,QTY) VALUES(CUTELEMENTN.CUTCODE,MAXTABCODE,CUTELEMENTN.ORDERCODE,MAXBED,RATIO(SIZESQTY),CUTELEMENTN.SHORTNAME,CUTELEMENTN.FABRICQTY)
SELECT CUTELEMENTN
SKIP
ENDFOR
ENDFOR
SELECT TABING
TABLEUPDATE(.T.) &&保存结果
ENDIF
ELSE
ENDIF然后剩下的一样，将这次产生的记录转入一个表打印出来，然后转入员工工资记录表，差不多了，可以列一下代码SUMSERIAL=ORDERING.SERIALNUM &&取出工序数量
SELECT * FROM TABING WHERE CUTCODE=SELCUTCODE INTO CURSOR TABINGN
SELECT TABINGN
COUNT TO REC
GO TOP
FOR CUTQTY=1 TO REC
FOR SERIAL=1 TO SUMSERIAL
SELECT SUMWORK
&&下行省略了具体数据，只说明意思
INSERT INTO SUMWORK(...) VALUES(...)
ENDFOR
SERIAL=1
SELECT TABINGN
SKIP
ENDFOR就是这样一个例子，如果工序数为12，那么这次就会产生24000条记录，不幸的是昨天有人告诉我他以前在UNIX下用C写的一个制衣软件工序会超过99个，死了！至于DELPHI下的代码，我就不用写了，我试过了VFP、Paradox、SQL-SERVER三种数据库(25000条)，速度都不敢令人恭维！其实就是上面那一点点代码，我想各位再怎么优化也优化不了那里去，这不是由数据库来完成！
在VFP中，建立一个6个字段的表，有日期、字符、数值三种类型，一条记录占33个字节顺次增加694000条记录，共花去15分钟，然后从694000条记录中SELECT出6940条记录花去17.32秒
在BCB种，怎么也出不来这么多记录，后来用一个现成的测试，通过ODBC从VFP数据库向ACCESS97数据库转数据，21个字段，包括日期、字符、数值三种类型，一条记录占336个字节顺次转移增加750条记录，共花去63秒！
机器：K6-2 500，两条HY -7 64M共128M！
当然，即与DELPHI有关，也与数据库有关（打开VFP数据库明显比ACCESS数据库快）。目前就是这样一种状况，我们是不是发动一下提供DELPHI增加记录的速度？
测试要求：在不同数据库中增加2万、10万、50万条记录所需的时间；从中选择1%记录所需时间；测试机器的CPU及内存。
OK！
别试验了，你的测试肯定是这个结果没有错误。
其实这两种应用的环境完全不同，自然没法比。 说老实话，单机环境，我还没有见过比foxpro更快的，
而且最快的不是那个VFP，是dos版本的foxpro 2.0, 如果论sql ，最快的2.5 for dos.
但是在分布式环境下，你试验一下把foxpro作为客户端，采用远程视图或者odbc驱动
再试验试验？那个速度比delphi更加不可恭维。
所以，foxpro的网络环境应用，几乎全是netware,nt下的文件方式访问。如果一定要比较，
不如比较运行在as400上的db2能够插入多少数据,查询多少数据。未必差劲多少。
但是，大数据系统也不用这个作为性能标准，而是用每秒的事务处理数。数据库发展到今天，分布式处理是趋势
你选择vfp来做，其实这个应用本身就不是分布式处理的应用，而是密集计算的应用。
当然，你这个应用也不是一个共享软件要求的access或者paradox级别的应用
对于大多数中小企业的应用，这样确实是现实，方便和成功的，因为他们的信息化建设
也就达到了“信息岛”的水平，部署分布式系统反而是累赘了：需要安装独立的服务器，
需要配置网络和网管，需要高水平的DBA, 需要在C/S两端部署和配置，等等。但是，用户的“信息化基础设施”不会停留在“部门级”或者“厂级”，更多的企业已经
发展到拥有很多的分公司，甚至是跨国公司的规模。客观上，就要求要进行跨地区，
7*24时间的处理和计算，数据和处理在客观上就是分布的，数据一致同步等都成大问题，
也没法采用这样一次性准备好然后处理的方式来完成计算。
只能采用分布处理，（集中存储，或分布存储/定期同步）的模式。所以，我觉得这个比较其实不是很公正，用单机系统一点之长比分布系统一点之短。
如果我来做这个系统，还是首先向用户建议采用分布式系统，或者采用大型数据库
这样有利于用户未来系统的扩展。
当然，如果项目时间短，钱少，或者人手少，或者用户根本不在乎，也会考虑用VFP，
毕竟VFP在数据库应用上的开发效率比delphi高太多了
如此大的数据量根本不适合单机数据库,最好还是用后端数据库服务器.
vfp没用过,不想用,完全是鸡肋,连pb都不如.
不过pb开发数据库程序确实比delphi高了很多(delphi是缺省的控件:P)
delphi的报表功能却比pb高了很多,用户完全自定义的报表pb就很难做,
delphi可以实现,不过也要花点功夫.