简体繁体 English

关系数据库查询建议

[英]Relational Database Advice For Queries

原文 2014-03-18 17:01:12 5 2 database/ syntax/ field/ table-relationships/ epicorerp

I am working with EPICOR and designing BAQ Reports. 我正在与EPICOR合作并设计BAQ报告。 My basic reports are always fine. 我的基本报告总是很好。 Now that I've moved on to building more complex queries, I wondered if there are any tips to help them work. 现在，我开始构建更复杂的查询，我想知道是否有任何提示可以帮助它们工作。 While my syntax is correct, verified by the program, my query still does not populate. 尽管我的语法是正确的，并且已通过程序验证，但我的查询仍未填充。 Any advice about what to look for? 关于寻找什么的任何建议？ What problems might cause delays? 哪些问题可能会导致延误？

2 个解决方案

I work with Epicor905.700c 我使用Epicor905.700c

I have noticed that if you ever have to flip the parent child relationship, the baq will almost never work. 我已经注意到，如果您不得不改变亲子关系，那么baq将几乎无法工作。 So it's best to add the table that you want to be the parent into the designer first. 因此，最好首先将要成为父表的表添加到设计器中。 ie XFileRef is by default a child of XFileAttch, so pull in XFileRef to the designer before you add XFileAttch. 即XFileRef默认是XFileAttch的子级，因此在添加XFileAttch之前将XFileRef拉到设计器中。 This is one thing that I wasted a few hours trying to figure out. 这是我浪费了数小时试图弄清楚的一件事。

If you are not seeing all of the data in your BAQ (and you have not added restrictive criteria), then it means you have written improper relationships between business objects. 如果您没有在BAQ中看到所有数据（并且尚未添加限制性条件），则表明您在业务对象之间编写了不正确的关系。 I've found that the internal Epicor tools do not typically validate relationships due to the fact that you theoretically could use such a join (for multi-company statistics, of full outer joins to dump many tables for archival, neither of which I recommend) 我发现内部Epicor工具通常不会验证关系，原因是您理论上可以使用这种联接（对于多公司统计数据，完全外部联接可以转储许多表进行归档，我都不推荐这样做）

Some quick tips related to writing BAQs and fixing relationships between business objects that should solve your issue with data populating: 一些与编写BAQ和修复业务对象之间的关系有关的快速提示，这些问题应可以解决数据填充问题：

Always link on BO.Company = BO.Company, then largest part, then smaller part, etc. For example, OrderHed linked to OrderDtl should be linked on Company, then OrderNum, then OrderLineNum, then OrderRelNum. 始终在BO.Company = BO.Company上链接，然后是最大部分，然后是较小部分，依此类推。例如，链接到OrderDtl的OrderHed应该链接到Company，然后依次是OrderNum，OrderLineNum和OrderRelNum。 If your business object is not linked on company, it will not be operating off of an index, and will make the query extremely slow. 如果您的业务对象未在公司上链接，则它不会在索引之外运行，并且会使查询非常慢。
If a query is experiencing performance issues, make sure your relationships are indexed. 如果查询遇到性能问题，请确保索引您的关系。 You can view this by going to System Management->Data Dictionary Viewer, and searching for the table you're working with. 您可以通过以下方式查看此内容：转到“系统管理”->“数据字典查看器”，然后搜索要使用的表。 Try to only use the indexes you see here to join two business objects together, or performance will suffer. 尝试仅使用此处看到的索引将两个业务对象连接在一起，否则性能会受到影响。 If you have a progress system, these indexes cannot be updated to my knowledge - so make sure you use them. 如果您有进度系统，那么就我所知，这些索引无法更新-因此请确保使用它们。
In general, if you do not have special reasoning behind the relationship direction, always make your base business object the smallest detail unit, and point the parents to the children. 通常，如果在关系方向后面没有特殊的推理，请始终使基本业务对象成为最小的明细单位，并将父级指向子级。 For example, if you are making a report that lists information on all of the order releases in a company, add OrderRel, then add OrderDtl and make sure OrderDtl points to OrderRel, then add OrderHed and make sure OrderHed points to OrderDtl. 例如，如果要制作一个报告，列出公司中所有订单发布的信息，请添加OrderRel，然后添加OrderDtl并确保OrderDtl指向OrderRel，然后添加OrderHed并确保OrderHed指向OrderDtl。 The way that Epicor translates this into the actual query depends on this ordering. Epicor将其转换为实际查询的方式取决于此顺序。
To speak specifically to this issue, start with a small number of business objects, adhering to the model set forth in #3, and make sure that your query is returning data. 为了专门讨论此问题，请从少量业务对象开始，并遵循＃3中提出的模型，并确保您的查询正在返回数据。 Add business objects one by one until you see less records returned. 一个接一个地添加业务对象，直到看到更少的记录。 This means that the data in the BO you added did not satisfy all of those relationship fields, and they will reappear if you click on the relationship line between the two and check the box "outer join". 这意味着您添加的BO中的数据不满足所有这些关系字段，并且如果您单击两者之间的关系线并选中“外部联接”框，它们将重新出现。 If you do this, you will not see field data from the new BO, because the relationship does not exist for that particular data, but it will not exclude the data from the BOs that were already working. 如果执行此操作，则将不会看到来自新BO的字段数据，因为该特定数据不存在该关系，但不会从已经起作用的BO中排除该数据。 In the example above, if you linked OrderHed with OrderDtl, and you saw some of your order lines go away, this would suggest that there is no order header for the order line that you selected, OR you incorrectly defined the relationship between those objects. 在上面的示例中，如果将OrderHed与OrderDtl链接在一起，并且看到一些订单行消失了，这表明所选订单行没有订单标题，或者您错误地定义了这些对象之间的关系。
As another user has said, do not flip the parent child using the right click->flip parent child, because this functionality is seemingly bugged in all versions of Epicor that I have yet seen. 正如另一个用户所说的，不要使用右键单击->翻转父级子级来翻转父级子级，因为此功能在我见过的所有Epicor版本中似乎都存在问题。 If you experience these problems, delete the business objects and relationships, save, and re-add them. 如果遇到这些问题，请删除业务对象和关系，保存并重新添加它们。 Although Epicor seems to handle the automatic population of relationships more consistently when this is done, I don't actually recommend adding the parent BO first. 尽管完成此操作后Epicor似乎可以更一致地处理自动的关系填充，但实际上我不建议您先添加父级BO。 I would use the method I describe in #4, saving in between each addition. 我将使用我在＃4中描述的方法，在每次添加之间进行保存。