SmartList Display Names Shown as Numerical Values Rather than the Display Name Shown in SmartList Builder
~ In SmartList Builder, the ‘Display Names’ are shown exactly as they were prior to the upgrade.
~ On the SmartList window (when a user actually runs a SmartList) the column headers (post upgrade) are displayed as 4 digit numerical values rather than being displayed as the value in the ‘Display Name’ field in SLB. For example: The Display Name field in SLB may show ‘Customer ID’ while the actual column header in the SmartList window shows ‘1001.’
~ If a user clicks ‘Columns’ at the top of the SmartList window, every value in the ‘Display Name’ column is shown as a 4 digit numerical values, but the ‘Original Name’ column still shows the correct values.
Is this something you have seen before? Do you have any idea what could be causing this issue? Any assistance you could provide would be greatly appreciated.
After digging through a bit of test data, it seems that the 4 digit # being shown as the ‘Display Name’ on the SmartList window is the ASI_Field_Number.
If I look at the Display Name in SLB for a field, I see it in the following 3 tables.
~ ASIEXP86 as ASI_Column_Display_Name
~ ASITAB20 as ASI_Field_Display_Name,
~ SLB10200 as SmartList_Display_Name
The value being shown on the SmartList window (when the SmartList is run) corresponds to the value in the ASI_Field_Number field in the same three tables listed above.
So now we know what is being used to populate the Display Name shown in the SmartList window, but we do not know what has created the error or how to correct the problem. Again, any assistance you are able to provide is greatly appreciated.
I can’t say I’ve seen where SLB uses the numeric field names for columns display names.
And there are any code changes that I can think of from 2013 to 2016 to account for that.
If you pull up the SmartList in SLB, I would assume that you would see the integers in the “Display Name” column.
So to fix the SLB10200..SmartList_Display_Name, could hand enter them into the smartlist. Or perhaps copy them in SQL from the SmartList_Field_Name potentially.
When you change the smartlist in SLB (like add a 1 to the name or something) and then republish it, then smartlist will change the ASITAB20 to the new name.
Nothing is going to change the favorite in the ASIEXP86 however. SInce on each favorite you can name the columns as you wish, nothing is going to change these values unless you open each favorite yourself and change them. or again you change them under the hood in SQL to the values you wish.
So as I note, can’t say that I’ve run into this with SLB before. But if you look at those tables for the GP SmartLists you’ll a lot of the columns are numbers. What that is for is to support multi-lingual installs. Those are the message numbers of the column names that get pulled from the dictionary.
It comes from the dictionary itself (in smartlist) but if you go to:
Select * from DYNAMICS..MESSAGES
then you can see the values that you’d expect to see. I guess you could potentially do an update query against the DYNAMICS..MESSAGES table to fix them as well.
For sure to make a backup before monkeying with any of this.
Thank you for the response. In this case, the customer came up with his own ‘fix.’ See below.
“I went in to each SmartList yesterday and corrected them so that they display the correct header information. All I did was open the SmartList, click the ‘Modify’ button, and save without making any changes whatsoever. That made the correct header information (rather than the 4 digit numerical column labels) visible, but it took me a few hours and I’m still not sure what exactly happened in the first place.
Now that you mention the table ASIEXP86, there’s a known issue when upgrading from GP2013 to GP2015. Unfortunately Microsoft won’t let you jump from 2013 straight to 2016; you have to move up to 2015 then 2016. Anyway, this is a known issue at Microsoft but I’m not sure if there’s a fix out there.”
The link to the original post (from the Dynamics Community) detailing the known issue he referred to is included at the end of this message, but I have copied and pasted the text here as well for ease of reference.
“You may encounter an issue with the ASIEXP86 table (SmartList Favorites Columns Master) when upgrading to Microsoft Dynamics GP 2015 R2:
‘The stored procedure SynchronizeTableData() of form duSQLAccountSynch : 27Pass Through SQL returned the following results: DBMS: 2601, Microsoft Dynamics GP: 0.’
BEFORE UPGRADING TO MICROSOFT DYNAMICS GP 2015 R2:
To identify whether or not you will encounter this issue, before upgrading, to Microsoft Dynamics GP 2015 R2, please run the following script against your DYNAMICS database:
SELECT * FROM DYNAMICS..ASIEXP86
WHERE ASI_Field_Number NOT IN (SELECT ASI_Field_Number FROM DYNAMICS..ASITAB20)
Here is the link to the above post: https://community.dynamics.com/gp/b/dynamicsgp/archive/2015/06/10/draft-known-upgrade-issues-when-upgrading-to-microsoft-dynamics-gp-2015-r2
So the remaining questions I have for you are as follows.
1. If the customer in this example had followed the suggested steps in the post above, would he have been able to avoid this issue?
2. If this is the same as the known issue for GP 2015 R2, do you think our customer encountered this issue because he had to go through GP 2015 in able to upgrade to GP 2016 or do you believe there could be some other cause?
3. Question 2 above is basically to help me answer this question: If the steps explained above can be used to avoid this issue when upgrading to GP 2016, should we provide them to our customers who plan to upgrade as a fix for a known issue when upgrading to GP 2016? We have had other customers upgrade to GP 2016 without issue. I am trying to figure out if t his is something unique to this particular customer’s environment or if it is something you would consider a ‘known issue?’
I don’t see how pressing “Modify” on the SmartList and taking back into SLB would fix this.
If it was initially modified by SLB (which you say it was since record in the SLB10000) then there isn’t any reason that SLB would then “fix” the column names. It should leave them the same.
Now if the GP smartlist was having issues and you then “modified” in in SLB – then I totally CAN see that it was fixed by SLB because we are hard coding the column names vs integers. But that isn’t the initial premise.
For your questions:
1. Well, we don’t have any detail on the exact nature of that bug. However that query they give is just looking for Favorites (ASIEXP86) where the columns have ID’s that don’t existing in the Fields table (ASITAB20).
I don’t see how that would tie into the issue you are seeing here.
2. I can’t see that it is the same issue.
3. As I noted, we’ve never seen this happen before. There was a Microsoft version of SLB 2013 but it doesn’t allow us to “modify” existing reports. And so assuming that you used the eOne version of SLB 2013 then and modified some reports, there isn’t any data upgrade between the versions so your SLB 2013 meta data would be the same going to SLB 2016 and should work fine.