"已解决 经 SPL 中的 exproc-bin 和 exprot-ext 两个 jar 包更新后查询正常 [图片] 这是我存入的数据，存到本地 btx 文件中 [图片] 这是存储过程 [图片] .."
这是我存入的数据，存到本地 btx 文件中
这是存储过程
但是查询本地 btx 文件查到的数据过少，图中我查询两年的数据，但仅仅只拿到 2021 年 1 月的一点数据
是我存入的数据是无序的吗？该怎么查呢？
看脚本是排了序的，理论上没问题。可以执行一下 file(…).cursor@b().select(signtime>=“2022-01-01” && signtime<=“2023-12-30”)看看计算结果是否按 signtime 有序，是否和 iselect 计算结果一致。如果不一致能否把数据文件上传一下？
按您的方法试了一下，查到的数据是按照 signtime 排序的！另外就是我写的 iselect 查询，只能查到 3 天的结果，比如我上面是从 1 月 1 日查到 12 月 31 日，就只查到了 1 月 1 日至 1 月 3 日，也是按照 signtime 排序的，不知道什么情况
一天大概多少条数据？我模拟一下试试
200 多，麻烦您了
我测试了一下没发现问题
file.iselect() 好用的很😄 刚把之前 VBA 写的耗时 56 秒，用集算器 iselect 优化到了半秒。这边用最近版本的集算器测试 btx.iselect@br() 针对有序文本日期字段二分查找，并没有发现数据不全的问题。集文件输出不是用 export@b()吗？ file(btx).export@z(A1.sortx();signtime) 中的 @z 选项是较老的版本？
z 选项在帮助文档中已经废弃，程序目前还保留着，这个选项是导出可分段集文件的意思。目前集文件只用 b 选项即可，集文件会自动根据数据量决定是否生成可分段的。
是的，老版本了
可能是我这的版本太低导致的什么 bug
确实，之前用这个在 200 多万数据里通过时间拿 20 多万数据也就 2 秒
换成新 jar 包还有问题吗？
不好换，服务器上还有以前的很多集算器脚本，报表的
1 先用新版本尝试一下是不是还有问题，确认是版本原因导致的2 除极少数情况外，脚本应该是一直能兼容的，升级应该不会出问题，稍做些测试就行了
看脚本是排了序的，理论上没问题。
可以执行一下 file(…).cursor@b().select(signtime>=“2022-01-01” && signtime<=“2023-12-30”)
看看计算结果是否按 signtime 有序，是否和 iselect 计算结果一致。
如果不一致能否把数据文件上传一下？
按您的方法试了一下，查到的数据是按照 signtime 排序的！另外就是我写的 iselect 查询，只能查到 3 天的结果，比如我上面是从 1 月 1 日查到 12 月 31 日，就只查到了 1 月 1 日至 1 月 3 日，也是按照 signtime 排序的，不知道什么情况
一天大概多少条数据？我模拟一下试试
200 多，麻烦您了
我测试了一下没发现问题
file.iselect() 好用的很😄 刚把之前 VBA 写的耗时 56 秒，用集算器 iselect 优化到了半秒。
这边用最近版本的集算器测试 btx.iselect@br() 针对有序文本日期字段二分查找，并没有发现数据不全的问题。
集文件输出不是用 export@b()吗？ file(btx).export@z(A1.sortx();signtime) 中的 @z 选项是较老的版本？
z 选项在帮助文档中已经废弃，程序目前还保留着，这个选项是导出可分段集文件的意思。
目前集文件只用 b 选项即可，集文件会自动根据数据量决定是否生成可分段的。
是的，老版本了
可能是我这的版本太低导致的什么 bug
确实，之前用这个在 200 多万数据里通过时间拿 20 多万数据也就 2 秒
换成新 jar 包还有问题吗？
不好换，服务器上还有以前的很多集算器脚本，报表的
1 先用新版本尝试一下是不是还有问题，确认是版本原因导致的
2 除极少数情况外，脚本应该是一直能兼容的，升级应该不会出问题，稍做些测试就行了