Classic Epicor BAQ - Black Magic _UD Table

If this has already been figured out, I missed the memo.

I’m sure many of us have been plagued by the random, but consequential, _UD table that sometimes comes into the classic BAQs. Just yesterday I created a very simple BAQ as part of an automated report; just saved it and went on my way. Today I saw the report failed because it tried to cross join our Part table for 3 retry attempts…This led to my discovery of how to replicate the _UD table:

At least in the scenarios my coworker and I tested, we were able to pin it down to clicking the New icon (not saving yet!), adding a table with UD fields and adding at least one of those UD fields to the display fields. Generating a new BAQ by typing it in and accepting the prompt doesn’t seem to lead to the same errant result.

I’m sure there are other ways to make this happen, but I was able to replicate this consistently. Tagging @timshuwy only because I remembered his comment from years ago on this thread BAQ Designer UD table appears out of the blue wondering how to replicate it. It’s unfortunate my own find came so close to the classic sunset.

3 Likes

Is it this?

It’s the same issue, but I didn’t see how to replicate it in there either. Mostly just people having similar issues and discussing how to work around the issue when it came up or what they thought could have been causing it.

The queries are both newly generated in my example, so nothing relating to uplifting older BAQs here.

1 Like

It’s almost like the BAQ you deleted hadn’t completely been cleared out yet so caused an issue when you created a new one with the same name, table, and field name.

If you waited a minute or two would it do the same?
Does closing the BAQ designer and reopening give the same result?
Have you enabled tracing?

1 Like

That’s fair, I should have closed the screen and used a different name in my posted example. I just booted Epicor fresh today with a new BAQ name and was able to successfully replicate the _UD table on the first try.

I hadn’t traced it yet, which is a failure on my part as an Epicor user. I just tried, and I can see in the BAQDesigner.Update method I receive this for the “good” BAQ:

        <QueryRelationDesigner>
          <Company>5051</Company>
          <QueryID>myTest2</QueryID>
          <SubQueryID>4e1da5e0-206a-470e-96bd-c2c861a5fba1</SubQueryID>
          <RelationID>12fe8054-9dac-48f6-9d5b-32d170063e89</RelationID>
          <IsFK>true</IsFK>
          <ParentTableID>Part</ParentTableID>
          <ChildTableID>Part_UD</ChildTableID>
          <JoinType>Inner</JoinType>
          <SysRevID>8770583609</SysRevID>
          <SysRowID>5eb63410-18b1-436f-b8f1-a2bc6ee39a0b</SysRowID>
          <OuterJoin>false</OuterJoin>
          <BitFlag>0</BitFlag>
          <RowMod></RowMod>
        </QueryRelationDesigner>
        <QueryRelationFieldDesigner>
          <Company>5051</Company>
          <QueryID>myTest2</QueryID>
          <SubQueryID>4e1da5e0-206a-470e-96bd-c2c861a5fba1</SubQueryID>
          <RelationID>12fe8054-9dac-48f6-9d5b-32d170063e89</RelationID>
          <Seq>0</Seq>
          <ParentFieldName>SysRowID</ParentFieldName>
          <ParentFieldDataType></ParentFieldDataType>
          <ParentFieldIsExpr>false</ParentFieldIsExpr>
          <ChildFieldName>ForeignSysRowID</ChildFieldName>
          <ChildFieldDataType></ChildFieldDataType>
          <ChildFieldIsExpr>false</ChildFieldIsExpr>
          <AndOr>And</AndOr>
          <Neg>false</Neg>
          <LeftP></LeftP>
          <RightP></RightP>
          <CompOp>=</CompOp>
          <SysRevID>8770583610</SysRevID>
          <SysRowID>5faa2016-a754-4040-89fe-02202a6bf0d1</SysRowID>
          <BitFlag>0</BitFlag>
          <RowMod></RowMod>
        </QueryRelationFieldDesigner>

But for the “bad” _UD BAQ the QueryID is blank, which seems to be contributing to the issue.

The GetByIDs are sort of expected then, where the “bad” BAQ pulls in the QueryRelationDesigner and QueryRelationFieldDesigner XML Blocks but the “good” BAQ does not.

Interesting. I have not been able to replicate this in kinetic BAQ designer in 25.2.16 but I only just tried it just now.

I feel the way the BAQ is first created in Kinetic lends itself to avoiding this issue. I also couldn’t replicate it in Kinetic, so hopefully this specific scenario will be a thing of the past.

1 Like

Always wondered about this, it’s so annoying when it happens and I have rework that table in the BAQ.