我正在尝试制作 ID 徽章应用程序。用户设计卡片,然后为该卡片创建数据输入表。因此,我在接受来自用户的字段(列、文本、行、图片、复选框、单选按钮、条形码等)后动态创建外部 DataWindow。现在,在为此目的创建表之后,我需要将此创建的 DataWindow(即时)转换为 SQL SELECT DataWindow。
我该如何转换?
我正在尝试制作 ID 徽章应用程序。用户设计卡片,然后为该卡片创建数据输入表。因此,我在接受来自用户的字段(列、文本、行、图片、复选框、单选按钮、条形码等)后动态创建外部 DataWindow。现在,在为此目的创建表之后,我需要将此创建的 DataWindow(即时)转换为 SQL SELECT DataWindow。
我该如何转换?
我要做的是使用您想要的 SQL 创建一个新的 DataWindow;不要费心调整 UI(我假设这就是你想要从原始 DW 中挽救的东西)。取出table()
新 DW 的部分并替换table()
原始 DW 的部分。确保正确匹配括号;该部分中有很多嵌入的括号集table()
。如果有疑问,请使用 NotePad++ 之类的工具为您找到匹配的括号。
这听起来很容易,这就是容易的部分。真正的关键,取决于数据集有多大,是确保数据集匹配,元素对元素,数据类型对数据类型。一个一个,你会以事后难以想象的难以追查的方式搞砸了。
祝你好运,
特里。
我第一次错过了“即时”部分,但同样的建议也适用;你只需要以编程方式完成它,这更难。当您不必忽略可能包含在 SQL SELECT 语句中的括号时,找到匹配的括号就足够具有挑战性了,更不用说在列值表达式等其他字符串中了。有可能,只是有很多难以预料的边缘情况需要测试,比如当 SELECT 语句中的字符串有一个左括号而没有右括号时会发生什么?然后必须以编程方式匹配数据类型,这在理论上意味着解析每个 DW 的列部分并比较数据类型。在实践中(没有这样做,只是折腾一个想法),您可以只使用两种语法 Create() 并查看两者之间的 ShareData() 是否失败。(ShareData() 允许一些灵活性,例如整数和长整数,我不知道这些差异是否会导致您尝试这样做的其他领域出现问题。)当然,这可能会引出一个问题:为什么不只是创建两组 DW 语法,一组外部语法和一组 SELECT,并在它们之间执行 ShareData()?
您会发现先创建表,然后从 SQL 中创建 DataWindow 要简单得多。您将能够使用您已经拥有的大部分代码来创建/修改 DataWindow 的可视化部分。
我建议您仔细考虑这种设计,因为用户迟早会想要对现有徽章设计上的数据进行更改,而如果不删除并重新创建表并迁移数据就无法完成。一个好的经验法则是永远不要让最终用户设计数据库。我将为您要支持的每种数据类型创建一个表,并将它们链接到带有属性标识符的徽章。用户唯一要做的就是添加可用数据类型的属性,给它们命名,然后将它们粘贴在徽章上。保留您的外部 DataWindow 并为每个受支持的属性类型使用 DataStore。如果您使用属性名称作为外部列名称,则可以轻松编写通用代码以在检索时从属性填充徽章并将属性复制回 DataStore 以保存。如果你会看看pfc_n_cst_dwsrv.of_populatedddw
(无参数版本)您将看到基本思想,除了您将查看列的数据类型并向处理该数据类型的 DataStore 发送请求,为其提供行和列名称(这是属性名称)填充。保存的工作方式相同,只是您为 DataStore 提供了要设置回 DataStore 的值。您无需担心数据是否更改,因为 DataStore 足够智能,可以判断它是否相同。如果您使用 PFC,您只需将更新列表设置为您的 DataStore,PFC 将为您处理它们(在这种情况下,您将使用 n_ds 作为 DataStore)。您还需要在 DataStore 中设置新行的标记 ID。您可以为此使用 n_dspfc_updatePrep
事件。
没有将外部数据窗口转换为 SQL Select 的自动机制。如果您熟悉 .srd 文件格式,则可以手动完成,但从头开始重新创建新 dw 要容易得多。
-保罗霍兰- SAP