是不是因为更新字典的原因啊    看二楼的日志

7886 数据字典更新中       ==> 总1 -- 当前0     0 20-12-15 08:36:14 开始处理 - 用时 0   0 开始数据处理 - 用时 0   0 导入数据,记录数 6334 - 用时 0   0 正在导入数据 - 用时 5   5 构建映射树 - 用时 0   5 更新数据字典 - 用时 0   5 数据字典更新中 - 用时 2   7 完成了 - 用时 0   7 20-12-15 08:36:21 处理结束 - 用时 0   7 20-12-15 08:36:21 处理结束 - 用时 457    10414 数据字典更新中       ==> 总1 -- 当前0     0 20-12-15 08:36:14 开始处理 - 用时 0   0 开始数据处理 - 用时 0   0 导入数据,记录数 6334 - 用时 0   0 正在导入数据 - 用时 5   5 构建映射树 - 用时 0   5 更新数据字典 - 用时 0   5 数据字典更新中 - 用时 2   7 完成了 - 用时 0   7 20-12-15 08:36:21 处理结束 - 用时 0   7 20-12-15 08:36:21 处理结束 - 用时 457   464 数据字典更新中 - 用时 2511   2975 数据字典更新中 - 用时 21   2996 数据字典更新中 - 用时 21

這個慢在我理解，應該是你保存或者刪除產品/單據信息后，  程序會進行相應字典的更新，所以當超過在定數量如5000條或者上條時，這時候程序就會轉圈圈，卡了。  二樓的日誌就是更新數據字典時的記錄。    一個解決辦法看看能否禁止系統作字典更新，特別是非常龐大記錄的數據字典或又如何實現分頁加載。  字典好像沒有分頁加載的說法？  那又如一樓所說的，加個環境參數，禁止更新這兩個最大型的字典更新罷了。    如  res  voucher啊，這類。

日志中的这一句，应该是最耗时的。如果系统能够优化下实现方式  select a.res_cat_id,a.res_cat_name,a.parent_res_cat_id,a.factor_num_show_mode,a.default_res_kind,b.tree_id,a.order_id from res_catalog a, app_tree_code_map b     另外，对于字典，像楼上所说的res,emp这类会产生很大的耗时与内存，比如在单据中的应用  那个 中文名称，此时调用的就是res的字典，如果数据库有20万条，那么用  db_copy_from_dt("res");  db_show()一下，真有20万条  不知道这样理解对不对，系统需要经常维护这20万条的字典，所以在单据页面、报表页面用到了这些字典的时候，就会很卡了。    如果是这样的话，其实可以作个建议，限制字典最大记录比如2000个（2000已经很多了，不会真的一个个下拉去翻来选择），超过时，就直接从表中去查询  这样是不是会快很多。  又比如，在产品资料的显示记录方面，更多的时候是查找，所以是否可以引入分布显示的方式，如附件所示

你把问题详细描述一下，截上相关界面，汇总成一份word文档，连数据库一起压缩发给我看看

也遇到同样，速度变慢的问题，点击保存等按钮时，系统没有反应，过一会才正常

提供ERP顾问咨询及落地实施，商业智能及数据分析BI，提供私有云、公有云环境的系统集成服务，QQ号：1138418237

数据作了一些脱敏处理，请忽视那些命名与描述。  从数据量上来讲，可以通过mdb方便测试时转mssql的不同版本问题（）。  比较卡表现在三个方面  1、是新建与保存产品资料  2、是刚打开单据及保存单据  3、是在使用脚本报表时，用到产品资料时 def_lmt_dict("lmt_res_id","产品字典","res");