十九世纪末，经典物理遇到过一个相当尴尬的问题。
按照当时已经相当成熟的理论去计算黑体辐射，频率越往紫外区域走，理论预测出来的辐射能量竟然会无限增大。实验结果显然不是这样。公式没有算错，实验也没有做错，真正出问题的是支撑那套计算方法的理论框架。
后来，这个问题有了一个很有名的名字，紫外灾难。
Max Planck 引入能量量子化之后，现代量子理论的大门才逐渐被推开。
SAP 从传统 ABAP 开发走向 SAP Fiori、RAP、ABAP Cloud 和 Clean Core 的过程中，也会碰到一些颇有这种味道的问题。不是某一行 ABAP 代码明显写错了，也不是某个 OData 请求直接失败，而是几种单独看都很合理的机制叠加以后，产生了非常反直觉的结果。
其中一个很典型的问题，就是 SAP Fiori elements List Report、BTP ABAP environment、Custom Entity、远程 OData 服务、本地扩展表以及分页机制同时出现时发生的数据丢失。
这种现象可以称作 SAP 世界里的 paging catastrophe，也就是分页灾难。
SAP Community 中已经出现了开发者对这一问题的完整记录，场景正是 SAP BTP ABAP environment 中的 Custom Entity 通过后端 OData 服务读取数据，同时还需要利用 BTP 本地字段进行过滤。
乍看之下，这不过是一个分页问题。真正深入到执行过程里，会发现它其实同时牵涉数据归属、过滤下推、OData 查询语义、RAP unmanaged query、无状态请求以及跨系统数据联邦。
问题的背景很符合现在越来越常见的
