EpiCombo not displaying data

9.05.702A SQL

Client has a HEAVILY customized Order Entry screen, which has two EpiCombo boxes to pull data from a UD table and store the values in UD fields (one a ShortChar and one a Character). On the initial Order Entry, they work flawlessly, and the data gets found and put where it needs to be, and everything downstream that uses that data works flawlessly too.

However, when you bring up an EXISTING order in the screen, those two EpiCombo boxes do not display anything. They are bound to the correct fields, and the fields contain data, but the boxes remain empty.

Except that’s not entirely correct either… if you open the Order Entry screen and enter (or search for and select) an order, the FIRST order shows data in those fields… but subsequent orders pulled up are blank for those two fields. Each time you open the screen the first order shows data, and all subsequent orders do not (for those two fields only).

Originally this used an adapter, but after this problem surfaced using that @josecgomez changed it to an EpiCombo (and if it would help I can screenshot the settings). It worked for a week or so and now it’s happening again.

Seems basic but a screenshot to validate would be nice. Does this happen to all users and different computers? Just trying to rule out personalizations and cache issues. The existing order does not show values even if the first time starting Epicor? Assuming they are active and no weird filters that seems odd. Are you getting any UI limitation messages on the client when using Order Entry?

Thanks Dan, it does the same thing for all users on all workstations (including me using both my login and the manager login). When you open Order Entry, the first order display is fine, any subsequent order is not. If you close Order Entry and then open it again (regardless of exiting Epicor), the first order is displayed correctly and completely, subsequent orders are not. Nobody is getting any UI errors.

Here is the Customization sheet for one of the fields:

If you enable tracing and then make it fail, do you see an entry in the trace logging for this method?

<tracePacket>
	<businessObject>Epicor.Mfg.Lib.BOReader</businessObject>
	<methodName>GetRows</methodName>
	<returnType>System.Data.DataSet</returnType>
	<localTime>2/14/2018 13:53:31:6628369 PM</localTime>
	<executionTime>21</executionTime>
	<parameters>
	<parameter name='boName' type='System.String' ><![CDATA[UD15]]></parameter>
	<parameter name='whereClause' type='System.String' ><![CDATA[(Key5 = 'Distributor') AND (Key2 = '000483')]]></parameter>
	<parameter name='columnList' type='System.String' ><![CDATA[]]></parameter>
	</parameters>
</tracePacket>

Nope, the only things that show up in a trace are SalesOrder.GetByID, SalesOrder.GetJobProd, SalesOrder.CheckCustOnCreditHold, SalesOrder.CheckOrderLinkToIntercompanyPO, and SalesOrder.OverCreditLimitUpdateAllowed.

This is AFTER having opened Order Entry and displaying one order, which displayed correctly. Then I turned on tracing and entered a second order number and hit tab.

You hit tab after entering the order and then can you click the drop-down?

If this were an open order I’d be able to hit the dropdown and select an option (according to the criteria in the customization)… even though there was already data in the bound field (that should be displayed but isn’t). In this case, it was a closed order, and the field was grayed out.

If you look at the earlier trace and find the field, in the GetByID portion of the trace, is there data being returned? Example:

<tracePacket>
	<businessObject>Epicor.Mfg.BO.SalesOrder</businessObject>
	<methodName>GetByID</methodName>
...

<Character09>123</Character09>

Yes, there are two, one for each field:

Epicor.Mfg.Lib.BOReader GetRows System.Data.DataSet 2/14/2018 15:59:43:9613651 PM 37

and then

Epicor.Mfg.Lib.BOReader GetList System.Data.DataSet 2/14/2018 15:59:47:8675660 PM 21

Is it possible some pieces of code were left from the old attempt. I doubt this but have to ask. Any chance you could post an export of the customization?

Nevermind - I was able to reproduce the issue with a very small customization.

Can you put the name of the column from your EpiBinding into the DescColumnName?
image

1 Like

I would avoid using a DescColumnName value. I believe the issue is the RowsDataSet vs ListDataSet. For UD tables it does not make a performance difference, but otherwise ListDataSet is often smaller (fewer fields queried).
If you use RowsDataSet, then your table should beUD15. If you use ListDataSet, then your table will be UD15List.

1 Like

RowsDataSet vs ListDataSet makes no difference. I tried both with both tablenames, and identical results (as is probably obvious, I’m not a programmer and am WAY out of my depth here).

When I put the binding in the DescColumnName, I got results… but it displayed the ValueMember and not the DisplayMember… but it successfully kept updating as I pulled in new orders. So from that and the trace yesterday, it looks like the system just isn’t doing the lookup for subsequent datasets.

I hate to say I’m glad you could reproduce the error @danbedwards, but I’m glad you could reproduce the error! The customization code is 983 lines and it’s a beast. I have been terrified that it’s something inside there that we’ll likely never find, but if you can do it with just a small customization that’s probably not the case.

@Jason_Woods, why would you “avoid” using the DescColumnName? Is it just because you knew it wouldn’t work, or is there other logic it brings in to play that I could learn about for the future?

Thanks to you both!

The avoidance of DescColumnName is just because that forces a value into a secondary field and it is that much more to setup.
As for the EpiCombo not populating, I assume you have sent in a Support ticket. Additionally, I would suggest that you use UserCodes for populating these combos (if appropriate). If you use UserCodes and populate the Extended Field Properties, then when you add the EpiCombo and set the EpiBinding, it populates all of the properties for you.