您在此处采用的方法不会产生良好的结果。

SQL是一种静态语言，其中表和列（以及它们如何相互组合）是数据类型。 如果定义" CUSTOMER"表，则所有" CUSTOMER"类型的数据记录将共享相同的结构。

诸如动态SQL或HANA 2 SPS 4的ANY TABLE TYPE参数的添加不会更改此结构。

从用例的描述（最终用户在UI中选择列，程序将所选列的列表移交给DB）中，这里所需要做的就是

您可以轻松扩展此方法，使应用程序为用户选择创建多带带的SQL语句。 如果您愿意，可以进行一些优化并将其称为"查询引擎"。 但是，实际上，该应用程序已经"知道"用户输入到列选择和结果集结构的转换应该是什么样子。
所缺少的就是从中构建一个SQL命令，运行它并以正确的结构返回结果。

以这种方式进行操作可以清楚地区分查询处理的动态部分的结束位置，从而非常直观地了解客户端向数据库发送的查询（而不是费尽心思 选择协议转换成SQL），并发挥DB优化器的优势（即处理静态SQL）。

查看几乎所有允许用户选择要返回哪些列（又称为报告前端）的应用程序，您会发现它们全部都按照我的描述进行操作：他们构建了一个查询命令

这就是做到这一点的方法-不是动态SQL。

我不建议"构建n个不同的查询"。

"仅"（实际上从来就不仅仅是"仅"吗？）构建您似乎希望在应用程序代码中的SQLScript代码中构建的"动态SQL"逻辑。 在几乎所有可用于应用程序代码的语言中，构建字符串都比在SQLScript中更轻松，更高效。

最重要的是，您可以执行在SQLScript中无法执行的操作，例如 根据您在检查中学到的知识，"检查"现有表结构并构建新结构（表，视图，函数，SQL语句）。
一个常见的例子是构建" PIVOT"查询器。 直截了当，例如JavaScript或Python，并且在SQLScript中确实很繁琐。

看，我知道当到目前为止，每个DB访问都可以通过绑定组件或 调用过程以获取结果集，所有活动部分都在DB模型或过程中完成。 但是，与如何动态地生成语句并运行它们相比，它所需要的额外学习很少。

无论如何，这就是我可以告诉您的这类问题， 如何在SAP HANA中进行处理。 祝你好运。