帆软报表按字段排序后，排名列为何不随排序动态更新？

Question

在帆软报表（FineReport）中，使用`RANK()`、`ROWNUM()`等函数生成的“排名列”常出现排序后排名不更新的问题。根本原因在于：帆软的排名函数默认基于**数据集原始顺序（即SQL查询返回顺序或模板加载时的静态行序）**计算，而非实时响应前端列排序操作。前端点击表头排序仅改变显示顺序，但不会触发数据集重算或排名函数重执行。若未配置“排序后重算”机制（如将排名逻辑移至数据库层用`ROW_NUMBER() OVER (ORDER BY ...)`实现，或在报表中启用「动态参数+条件查询」配合排序字段联动），排名列将始终固化为初始加载时的结果。该问题多发于普通表格（非决策报表）的客户端排序场景，是初学者高频踩坑点。

Answer 1

```html

一、现象层：前端排序后排名列“凝固不动”——最直观的故障表征

用户在普通表格（非决策报表）中点击任意列标题触发升序/降序时，其余字段实时重排，但使用 RANK($A)、ROWNUM() 或 INDEX() 生成的排名列数值完全不变。例如原始数据按销售额降序加载时排名为 [1,2,3,4,5]，当用户点击“地区”列升序后，行物理顺序已变，但排名仍显示 [1,2,3,4,5] —— 仿佛被“焊死”在初始行号上。

二、机制层：帆软渲染引擎的双阶段执行模型

• 阶段1（服务端）：SQL查询执行 → 数据集加载 → 模板解析 → RANK() 等函数基于ResultSet原始游标顺序一次性计算并固化结果；
• 阶段2（客户端）：浏览器仅对已渲染的HTML表格DOM节点执行sort()操作，不发起AJAX请求，不重载数据集，不重触发公式计算。

该设计保障了交互性能，却造成“显示逻辑”与“计算逻辑”的解耦断裂——这正是所有排名失同步问题的底层架构根源。

三、归因层：三大典型误用模式与技术动因

误用类型	典型写法	失效场景	根本原因
静态公式嵌入	RANK($F2,"desc")	点击其他列排序后	公式绑定单元格而非动态上下文
客户端分页干扰	启用“客户端分页”+ ROWNUM()	翻页或排序后排名跳变/重复	ROWNUM() 在每页独立计数，无全局序
未启用参数联动	排序字段硬编码，无$sortField参数	前端排序不触发SQL重查	缺乏“排序即查询”反馈闭环

四、验证层：快速定位是否为真·排名失同步问题

1. 右键表格 → 【查看数据】确认原始数据集顺序是否与当前显示一致；
2. 打开【模板Web属性】→ 勾选「支持客户端排序」→ 观察控制台Network是否出现/report?op=write请求（无则确认为纯前端排序）；
3. 将排名公式改为 IF(1=1, "DEBUG:" + ROWNUM(), "") 并刷新，排序后若DEBUG前缀不变，则证实公式未重算。

五、解法层：四维协同治理策略（含代码与流程图）

以下为推荐优先级从高到低的解决方案：

graph LR A[问题触发] --> B{是否允许修改SQL？} B -->|是| C[数据库层：ROW_NUMBER() OVER
ORDER BY ${sortField} ${sortOrder}] B -->|否| D[帆软层：动态参数+条件查询] C --> E[返回带rank字段的结果集
前端直接引用$rank] D --> F[定义sortField/sortOrder参数
SQL中拼接ORDER BY #sortField# #sortOrder#] F --> G[勾选“排序时刷新参数”] G --> H[排名列改用$rank字段
禁用RANK()函数]

六、增强实践：决策报表 vs 普通表格的路径差异

-- ✅ 推荐：数据库窗口函数（兼容Oracle/MySQL 8.0+/SQL Server）
SELECT 
  region,
  sales,
  ROW_NUMBER() OVER (ORDER BY sales DESC) AS rank_by_sales,
  RANK() OVER (ORDER BY region ASC) AS rank_by_region
FROM sales_data
WHERE ${if(len(sortField)=0,"1=1", sortField + " IS NOT NULL")}
ORDER BY ${sortField} ${sortOrder}

注意：在普通表格中必须将上述SQL绑定至数据集，并在单元格中直接引用$rank_by_sales；若强行在单元格写RANK($sales)，仍将落入客户端静态计算陷阱。

七、进阶防御：构建可审计的排名一致性校验机制

• 在报表初始化脚本中注入：window._FR_RANK_CHECK = function(){...}，监听fr-sort事件并比对$rank与实际行序偏差；
• 开发自定义函数CALC_RANK(col, order, scope)，内部调用contentPane.getCellValue()动态采集当前可见行值再排序；
• 对TOP N榜单类报表，强制启用「服务端排序」+「服务端分页」，彻底规避客户端排序链路。

八、避坑清单：5年+开发者验证过的高危操作

1. ❌ 在「分组汇总」表格中对子组内使用ROWNUM()且开启折叠/展开；
2. ❌ 将RANK()置于「条件属性」的样式表达式中（仅影响样式，不参与排序逻辑）；
3. ❌ 使用INDEX()替代ROWNUM()——二者均基于模板加载时的静态行索引；
4. ✅ 正确姿势：所有排名需求优先下沉至SQL层，次选帆软「参数化排序+服务端重刷」；
5. ✅ 高级场景：结合FineReport 11.0+ 的「智能排序」API：contentPane.sort("sales", "desc", true) 强制触发重算。

九、演进视角：FineReport 11.x 对排名语义的增强支持

新版引入DS_SORTED_RANK(dsName, fieldName, sortType)函数，其内部自动监听数据集排序事件并重计算——但需满足两个前提：
① 数据集配置为「服务端排序」；② 字段映射名与SQL别名严格一致。此函数标志着帆软正从“静态公式引擎”向“响应式数据流引擎”演进。

十、结语：排名的本质是序关系，而非行号标签

真正的排名永远依附于某个明确的排序维度与作用域（全量/分组/分页）。当开发者把RANK()当作“自动编号”使用时，已背离其数学定义。理解FineReport中「数据流生命周期」与「UI渲染生命周期」的异步性，是跨越初级陷阱、进入架构级优化的关键认知跃迁。

```