在 Acumatica 中使用 SQL 和 BQL 的缺点是什么

Question

我一直在处理一个非常具体的用户请求。最终目标是根据 INLocationStatus 中的库存可用性更改 FSServiceOrder、FSSODet、FSAppointment、FSAppointmentDet 上的用户定义字段。

我有一个处理屏幕，因为它需要按需运行或按计划运行。 注意：用户从未真正与处理屏幕上的任何内容进行交互。他总是会简单地点击：“Process All”

为此使用 BQL 似乎不合时宜。

在我的处理事件中使用加入：

    public PXProcessingJoin<INLocationStatus, 
         LeftJoin<InventoryItem, On<INLocationStatus.inventoryID, 
         Equal<InventoryItem.inventoryID>>>>   Processing;

作为一个起点不是很有帮助。

如果不在处理事件中运行单独的 BQL，我什至无法从连接表中获取值。 （如果我理解正确的话。我发现没有办法做到这一点，而这个SO似乎表明这是不可能的。）

所以我必须在我的处理委托中运行 BQL，以获取库存信息。在处理每个 DAC 时，我还必须执行多个 BQL——而且我还必须创建多个 PXGraph。

这似乎有很多开销——而我真正要做的只是将数据读入内存缓存，处理它，然后设置一个用户定义的字段。

我知道使用 BQL 的价值在于它可以确保执行所有业务逻辑，但就我而言，这并不适用。我可以确定没有需要运行的业务逻辑。我只是简单地遍历数据行，计算我自己在内存中的可用库存值，然后在数据库中设置一个 usr 定义的标志。

直接调用 SQL，获取我的数据，然后更新标志不是更好吗？如果我这样做，是否会引起我没有考虑的问题？还是会在未来产生巨大的问题？

还有其他人在处理屏幕中混合了 BQL 和 SQL 吗？

Answer 1

标记，

如果您确信更新用户定义的字段不会引发意外后果，那么我不会担心。如果您需要让 Acumatica 认证您的代码，但他们不会支持它。我认为直接更新数据库的唯一意外后果是它不会通知应用程序缓存已经进行了更改（除非 PXDatabase 函数这样做而我只是没有意识到）并且另一个用户可能会得到“另一个进程在尝试编辑同一记录时已更新...记录”错误。

Answer 2

Acumatica 在将缓存保存到数据库之前使用时间戳来验证缓存。为什么不使用Linq 查询来获取数据，根据图表设置它们并让标准的持久化方法使用 Save.PressButton 来处理它们？

我之前尝试过更新表格，但是当进入屏幕加载数据时出现错误“另一个进程已更新 PX...”。

我知道这似乎需要做很多工作，但我宁愿这样做也不愿花几个小时试图再次修复时间戳。